build: fix MinGW-w64 cross-compilation for Windows - #443

This lets monkey build for a Windows target with the MinGW-w64 UCRT toolchain (GCC), in addition to MSVC. Everything MinGW-specific is gated on MINGW/__MINGW32__ (or falls under existing !__MINGW32__ guards), so MSVC builds compile the same code as before.

Build fixes (build: fix MinGW-w64 cross-compilation for Windows):

• Set _POSIX_THREAD_SAFE_FUNCTIONS so MinGW declares the POSIX *_r time functions (localtime_r, ...), and keep the incompatible-pointer-type mismatches (Winsock recv/send/getsockopt take char* buffers where POSIX uses void*) as warnings — GCC 14+ otherwise rejects them as errors, while MSVC accepts both.
• Select the POSIX threading model on MinGW, which ships a real pthread implementation (winpthreads); the hand-rolled Windows pthread shim stays MSVC-only.
• Guard the MSVC-only typedefs and shims (mode_t, pid_t, timespec, the nanosleep/localtime_r replacements, the stdint fallback) that the MinGW headers already provide.
• Widen MSVC-only gates that cover Windows functionality (the glob fallback, _fullpath, MK_INLINE) to _WIN32.
• Use the standard GCC container_of on MinGW; the PCHAR/ULONG_PTR variant relies on Windows SDK typedefs only MSVC pulls in implicitly.
• Lowercase capitalized Windows header includes so they resolve on a case-sensitive filesystem when cross-compiling from Linux.
• In the bundled flb_libco, check _WIN32 before the architecture so x86_64 MinGW selects the fiber backend instead of amd64.c (whose co_swap runs a read-only machine-code blob that faults under DEP on the first coroutine switch), matching the MSVC branch that already disables amd64.c. This same fix is submitted upstream to flb_libco as libco: select the fiber backend on Windows edsiper/flb_libco#12 — monkey's vendored copy can drop it once that merges and flb_libco is re-synced.
• For the bundled libevent: record the winsock dependency on the static archives; and, for MinGW only, pin NTDDI_VERSION next to the existing _WIN32_WINNT override in evutil.c (its sdkddkver.h errors when the two disagree, where MSVC does not, so MSVC compiles the file unchanged) and define EVENT__HAVE_STRTOK_R (libevent's WIN32 function check takes the function's address and only sees the force-included winsock headers, so it mis-detects strtok_r from <string.h> and then defines a conflicting static copy).

CI (workflows: add a MinGW-w64 cross-compile check): a new build-windows-mingw job cross-builds monkey as a library from Linux with the Fedora MinGW-w64 UCRT64 toolchain, alongside the existing MSVC Windows job, so the MinGW support doesn't regress. It uses the same library-only profile (MK_LIB_ONLY, no bin/conf) as the MSVC job.

Testing

• Cross-compiled monkey as a static library with the Fedora MinGW-w64 UCRT64 toolchain (the exact command the new CI job runs) — builds cleanly, libmonkey.a produced, 0 errors.
• Verified in context by cross-compiling Fluent Bit (which vendors monkey) for Windows from Linux with the same toolchain — monkey compiles and links into a working fluent-bit.exe (PE32+ x86-64).
• The MSVC path is unchanged: the MinGW-specific defines/gates are scoped to MINGW/__MINGW32__, and evutil.c compiles byte-for-byte as before under MSVC.