Use POSIX on Windows when building with mingw-w64 toolchain

[eramongodb]

Related to CXX-3180. Addresses the following compilation error observed when built with mingw-w64 GCC on Windows:

error: implicit declaration of function 'InitOnceExecuteOnce' [-Werror=implicit-function-declaration]
      |     bool okay = InitOnceExecuteOnce(&flag->_native, &_mlib_win32_once_callthru, &fn, NULL);
      |                 ^~~~~~~~~~~~~~~~~~~

Given systems where mingw-w64 GCC toolchains are installed typically include the POSIX library, this PR propoes restricting the conditions used to select Windows headers to "building with MSVC" (defined(_MSC_VER)) only instead of "targeting Windows" (defined(_WIN32)).

(There is the possibility that _WIN32_WINNT could be used per this SO post, but I'd prefer not to introduce Windows-specific library configuration macros if we can help it.)

[kevinAlbs]

LGTM.

There is the possibility that _WIN32_WINNT could be used per this SO post

Aside: I expect defining _WIN32_WINNT would work based on the latest MinGW headers. Defining _WIN32_WINNT might be slightly preferable to avoid any quirks in another thread implementation (MinGW's implementation looks non-trivial). But I think that is a minimal risk.

[eramongodb]

quirks in another thread implementation

I have a suspicion that the "proper" fix (if we want to continue using Win32 threads, which I'm not sure we want to) may be to set an appropriate value for the CMAKE_SYSTEM_VERSION CMake variable similar to what is currently done for the C Driver's compile-std task here, but I have not managed to investigate this approach deeply enough to be sure.

We may also need to eventually decide and publically document exactly what we mean by "mingw" support, considering the wide parameter space of "mingw" toolchains available (ucrt vs. msvcrt vs. MCF runtime libraries, pthread vs. win32 threads, SEH vs. SJLJ exceptions, i686 vs. x86_64 target architectures). As far as I am aware, the most likely and recommended configuration used and expected by modern Windows development environments is ucrvt + pthread + seh + x86_64, and that is the one this (and upcoming) PRs related to CXX-3180 are working towards. I'm not sure if we want/need to support any more mingw-related toolchains beyond just one: ideally our libraries should be agnostic and require users feed CMake the appropriate flags and options to support their bring-your-own-toolchain, but since we are distributing pkg-config files on Windows, we have to make a choice somewhere along the way about exactly what toolchain the libraries described by the pkg-config files were built with.

[eramongodb]

On second thought, we may want to go with _WIN32_WINNT after all, for consistency with the C Driver library's <bson/compat.h> behavior (if that is behavior we wish to continue supporting).

[vector-of-bool]

LGTM, but your decision whether to go through with it.

[eramongodb]

we may want to go with _WIN32_WINNT after all

Will postpone considering this alternative solution for the future, given these changes should only affect internal code (not part of public API, unlike <bson/compat.h>).