I forgot to rename it in my previous refactoring of pytime.c.

_PyTime_Divide() rounding was wrong: copy code from Python default which has
now much better unit tests.

On Windows, the tv_sec field of the timeval structure has the type C long,
whereas it has the type C time_t on all other platforms. A C long has a size of
32 bits (signed inter, 1 bit for the sign, 31 bits for the value) which is not
enough to store an Epoch timestamp after the year 2038.

Add the _PyTime_AsTimevalTime_t() function written for datetime.datetime.now():
convert a _PyTime_t timestamp to a (secs, us) tuple where secs type is time_t.
It allows to support dates after the year 2038 on Windows.

Enhance also _PyTime_AsTimeval_impl() to detect overflow on the number of
seconds when rounding the number of microseconds.

I was not supposed to commit the function with the name pymonotonic_new(). I
forgot to rename it.

Don't check anymore at runtime that the monotonic clock doesn't go backward.
Yes, it happens. It occurs sometimes each month on a Debian buildbot slave
running in a VM.

The problem is that Python cannot do anything useful if a monotonic clock goes
backward. It was decided in the PEP 418 to not fix the system, but only expose
the clock provided by the OS.

Fix also _Py_InitializeEx_Private(): initialize time before initializing
import, import_init() uses the _PyTime API (for thread locks).

_PyTime_AsMicroseconds() rounding.

Add also unit tests.

using the C volatile keyword.

Use _PyTime_ROUND_FLOOR and _PyTime_ROUND_CEILING instead.