clock: return signed ints from time64 functions

Changed return value type in Lua for the following functions from
`uint64_t` to `int64_t`:

* clock.time64
* clock.realtime64
* clock.monotonic64
* clock.process64
* clock.thread64
* fiber.time64
* fiber.clock64

Changed return value type in Module API for the following functions from
`uint64_t` to `int64_t`:

* fiber_time64
* fiber_clock64

Also enhanced clock.test.lua tap test with more testcases

Due to unsigned values returned from time64 family function time
calculations may lead to undesired value overflows. Having two 64-bit
timestamps I cannot just subtract them without prior comparison. It is
used often, for example when calculating time to a deadline (in queues
or for expiration).

Let's measure time, that pass between two sequential clock.time calls:

```lua
print(clock.time() - clock.time()) -- -9.5367431640625e-07
```

It's ok, with double type time return, but what about 64-bit integers?

```
print(clock.time64() - clock.time64()) -- 18446744073709550616
```

It returns weird integer overflow instead of expected `-1000`

This is counterintuitive and gets conflicted with every time functions
from system headers (which are always signed).

If we consider some hypothetical code, that waits some time for a
deadline, then instead of exiting loop, this code will go to "infinite"
(actually 585 years) wait in the case when the deadline was passed.

```lua
do
local ts = clock.time64() + 1e9 -- some_timestamp_in_future, ex: now+1s
-- ...
local remaining = clock.time64() - ts
-- ...
if remaining > 0 then
    fiber.sleep( tonumber(remaining/1e9) )
end
print "1 second passed"
end
```

This is hard to notice (in real tests deadlines are always in the
future), but in a real environment and under high load such cases occur.

1. Since Lua functions will return ffi.typeof `ctype<int64_t>` instead
   of old `ctype<uint64_t>` any code, that uses _strict_ ffi type check
   will fail. But I hardly believe such code ever exists.
2. Low-level Module API also changed, and code, which compiles with
   `-Werror` may also fail. This could be an issue and in such a case we
   may remove the update of module API change. Still, I consider this
   change reasonable, since all C-level API uses signed time values.

@TarantoolBot document
Title: Return type of time64 functions is changed

These C functions in the public API used to return `uint64_t`, now they
return `int64_t`: `clock_realtime64`, `clock_monotonic64`,
`clock_process64`, `clock_thread64`, `fiber_time64()`,
`fiber_clock64()`.

These Lua functions used to return cdata of type `uint64_t`, now they
return cdata of type `int64_t`: `fiber.time64()`, `fiber.clock64()`.