Use WinAPI concurrency primitives on Windows ports (remove winpthreads)

[MisterDA]

The goal is to remove winpthreads (a library emulating pthreads on top of old Windows APIs), and use modern Windows APIs in both the MSVC and MinGW-w64 ports.

It would be great if this PR could be considered for inclusion in 5.3: although we were already using the system winpthreads for the MinGW-w64 port, we introduced it as a submodule during the 5.3 development cycle to support the MSVC port. If we could remove it now, end users won't ever (unknowingly) depend on it.

One commit removes winpthreads (breaks OCaml build on Windows) and another implements the caml_plat_* and st_* functions required to abstract over pthreads and Windows concurrency APIs.

Note that Windows Mutex Objects cannot be used with condition variables. The right pairing consists of Slim Reader/Writer Locks (SRW locks) and condition variables. SRW locks support shared locking (only readers) and exclusive locking (one writer). I've chosen to use exclusive locking in all cases. Windows condition variables have the problem that they cannot be statically initialized.

Both pthreads and WinAPI are quite similar, except for a few points that I've noted:

1. The type of a function that starts a thread. They return a void * pointer on pthreads, and an unsigned int on Windows, but it seems not to be a concern for us.

2. We use pthread ERRORCHECK mutexes. POSIX states:

   The pthread_mutex_lock() function shall fail if:
   [EDEADLK]
   The mutex type is PTHREAD_MUTEX_ERRORCHECK and the current thread already owns the mutex.

   The Windows documentation states:

   Exclusive mode SRW locks cannot be acquired recursively. If a thread tries to acquire a lock that it already holds, that attempt will […] deadlock (for AcquireSRWLockExclusive).

   Deadlocks caused by recursive attempts to lock cannot be detected on Windows. We cannot either detect double unlocks, or attempts to unlock a lock owned by another thread. This would revert the Stdlib.Mutex module guarantees to those of before OCaml 4.12 on Windows only.

   I've thus chosen to implement so-called ERRORCHECK mutexes with a pair of a SRWLock, and the thread id of the owner, accessed atomically. The value 0 is used when the thread is not owned, and is a valid sentinel value.

3. A Windows thread is "detached" if all handles referring to the thread have been closed: it cannot be joined (waited on in Windows terminology) anymore but is not ended. pthread has a thread attribute to control the detached state.

[shym]

This looks good to me, even if this scraps out much of my code :-)

I just noted a couple of small suggestions:

• 04b344f Implement concurrency primitives using WinAPI
  Maybe add in the commit message explanations about:

  • how code is reshuffled (what moves into unix.c, etc.)
  • detaching threads on Windows; also add a small comment in the _detach function about that (the handle cannot be duplicated, can it?)

  Is there a reason not to typedef HANDLE caml_plat_thread instead of casting it on occurrences?

  Could caml_plat_thread_create have the same signature on Windows (maybe asserting that only the supported attributes are used (only NULL, maybe? or also detached?))

[shym]

I’ve reviewed the range-diff with the previous version I had reviewed. This looks good!