This PR alters the mingw-w64 build to link the winpthreads library statically, removing the need for additional runtime DLLs (or, another way, restoring the OCaml 4.x lack of need for additional runtime DLLs).

Doing this proved slightly more complicated than I'd expected, as it turns out that GCC's implementation of implicit TLS (__thread) pulls in both its runtime library and also dynamically links the winpthreads library when building DLLs. This is something we've avoided in the past in the i686 port by using -static-libgcc but not only is that slightly worrying to have to do for the 64-bit port as well, but it also doesn't work for the pthreads linking.

This PR consists of three very closely linked parts:

• The PTHREAD_ machinery from otherlibs/systhreads/Makefile is removed as pthreads is now always linked as part of the runtime and it would result in double-linking when switching to static winpthreads.
• On Windows, Caml_state now uses a similar technique to pthread_getspecific on macOS, rather than implicit TLS via __thread. As a very minor aside, the SET_Caml_state macro is shifted inside a CAML_INTERNALS block, since it's only used in domain.c where we can actually load the required Windows headers to use TlsSetValue (more on this below).
• winpthreads is then linked statically, which requires support -l: library linking specification flexdll#106 (this PR teaches flexlink to understand -l: syntax).

For background, there is no better explanation of Windows TLS than Ken Johnson's Nynaeve Adventures in Windows debugging blog (one should also, of course, read Raymond Chen on the same subject).

The way I propose implementing Caml_state warrants (considerable) further explanation. The problem with Caml_state is that it's in a public header. Our headers and codebase do not interoperate well with windows.h (cf. the trickery required around ATOM) and it seems best to keep it that way, as it's likely that user code suffers the same problem. This already means that the macro implementation of Caml_state wants to avoid using Windows API functions and types, because we have to declare compatible versions in the header, and it's really awkward. Coupled with that is the fact that TlsGetValue somewhat inexplicably insists on clearing GetLastError (see the related previous fix in #10220), I've elected here to expand the macro definitions from winternl.h for NtCurrentTeb and then have caml_make_domain_state_key both reserve a TLS slot and also compute the offset in the TEB where that TLS slot will be.

I did implement a version which instead included windows.h, but this involves some really ugly pre-processor mucking with symbol names in various other files (both in the debugger and in the interpreter). I also looked at the alternative with manual declarations for TlsGetValue, SetLastError and GetLastError and it's similarly hideous and, frankly, looks more brittle than just computing the TEB offset for the TLS slot. It's also fundamentally upsetting to have to make 4 system calls and 2 branches just to dereference a single pointer! I also experimented just doing it the macOS way and using winpthread's pthread_getspecific but this also suffers from the fact that we're in a public header and directly exposing pthreads in this way makes linking potentially awkward for user C code. The stub DLL for systhreads has to jump through a minor hoop to do this, but that seems acceptable for that one library. For Windows, winpthreads provides a nice abstraction for simpler code in most of the runtime, but I don't think it's a good idea for the fact we do this to be exposed in the API (the sync module, etc. hides the implementation of the primitives).

Back in Windows 9x days, manually reading the TEB would have been utter madness - the 16 bit implementations of TLS have actually changed between versions of 16-bit Windows. However, since the very beginning of Windows NT, both the C compiler and loader have colluded on the "internal" format of the TEB in order to implement implicit TLS (with quite a few infamous limitations along the way, which is why GCC uses some emulation). A side-effect of this collusion is that the TLS layout in the TEB pretty much cannot change (but you of course read all 8 parts of Nynaeve and therefore have already read that!). So what I'm proposing here is actually what the C compiler should be doing (and, when MSVC gets resurrected, is possibly what the MSVC port will actually do, although I confess I'll be surprised if it actually works across DLL loading and flexdll). I have chosen to restrict the implementation to the first 64 TLS slots only (later in the TEB is a pointer to the other 1024 slots added with Windows Vista). This should be no problem at all for ocamlopt-compiled programs (I think there are 3 other TLS slots in use before this one gets allocated); some particularly strange "OCaml called from C" implementation should hopefully be able to call caml_make_domain_state_key before allocating gazillions of TLS slots.

Given the DLL hell which can arise on mingw-w64 (see all the fun in opam for manifesting the C++ mingw-w64 runtime DLLs), I hope that one slightly hairy macro definition and a bit of dirty pointer arithmetic is an acceptable cost. As it happens, the combined facts the the TLS slot is set using TlsSetValue and then retrieved directly from the TEB coupled with quite how fundamental Caml_state is to the runtime means that this all gets quite severely tested just building the compiler, let alone running the testsuite!

This PR is marked as Draft only to prevent merging before the FlexDLL PR is merged. This branch has been through precheck#778.