Sub-microseconds sleeps on Windows

[MisterDA]

By using a high-resolution timer, available since Windows 10 RS4
(1803), we can attain sleeps with a 100 nanosecond precision.

A handle representing the high-resolution timer is required for a
thread to sleep. In order to avoid paying the cost of creating and
closing the timer, it is re-set (reused). The timer needs to be stored
somewhere: the domain state is not a good fit as the domain state
cannot be accessed once the runtime system is released, which is
typically the case before a sleep. Moreover, multiple systhreads
belonging to a single domain might want to sleep simultanously.
The systhread structure isn't a good fit either, as runtime threads
don't have access to this. Thread-local storage is a viable option.

Timer handles are created on-demand at the first
caml_win32_nanosleep call of the thread. The first thread entering
this function tests if timer handles can be created at all (with a
PINIT_ONCE, the equivalent of pthread_once), as the feature might
not be supported by the Windows host. Other threads then check if
have_high_resolution_timers is true, and if so, attempt to create
timers.

It seems difficult to precisely know when to close this handle, in
each and every case. To defend against mistakes, we keep a linked list
of these handles. In some cases, threads will close their timer handle
to prevent handle exhaustion when they exit. In the general case, they
will be closed during caml_shutdown.

This commit allows more precision in the platform spin-waits, and also
avoids rounding down quirks: Sleep(0) will put the process at the
end of the process queue, without sleeping.