Fix build break due to calling convention mismatch on Windows

Avoid polluting the build directory a small amount given that we can use
`-fmodule-map-file=` for the C/C++ build of libdispatch.  Unfortunately,
for the Swift build, we need to have the file copied over due to the
umbrella header resolution.

Hopefully this reduces some of the race conditions that we have seen in
the build.

Thanks to @dgregor for reminding me of the flag!

Use a VFS overlay to avoid polluting the source tree.

build: slightly improve the build for libdispatch

This is an `enum` with associated values of `Int` type that are all `Sendable`, so should be safe mark the whole `enum` as such.

Resolves #787.

The `WaitChain*` functions require linking against AdvAPI32.

build: add a link against AdvAPI32 on Windows

This function is the initializer for the semaphore.  The seamphore
storage itself may be stack allocated (or heap allocated) but without
guarantee of 0-initialisation.  As a result, the subsequent CAS for the
atomic replacement will fail silently, leaving the previously non-zero
value in place, indicating that the value is a valid handle.  This would
fail randomly and would ultimately result in a crash in the
`CloseHandle` call associated with the clean up.

This issue was identified by SwiftLint on Windows.

shims: fix a subtle bug in semaphore initialisation on Windows

There is a subtle difference between libdispatch built dynamically and
statically: DispatchStubs.  We erroneously emit ObjC runtime calls into
the build and the stubs provides a shim to provide a definition on
non-ObjC runtime enabled targets.  When built dynamically, this is
internalised and distributed as part of dispatch.dll/libdispatch.so,
however when built statically, the consumer is responsible for linking
against DispatchStubs.  The modulemap reflects this and we need to
ensure that we correctly provide that modulemap.

Thanks to @MaxDesiatov for the help with debugging and testing a fix for
this!

Fixes: rdar://23335318

There is a subtle difference between libdispatch built dynamically and statically: DispatchStubs. We erroneously emit ObjC runtime calls into the build and the stubs provides a shim to provide a definition on non-ObjC runtime enabled targets. When built dynamically, this is internalised and distributed as part of dispatch.dll/libdispatch.so, however when built statically, the consumer is responsible for linking against DispatchStubs. The modulemap reflects this and we need to ensure that we correctly provide that modulemap.

Thanks to @MaxDesiatov for the help with debugging and testing a fix for this!

Related: rdar://23335318

Prevent infinite attempts to write to Win32 pipes