This removes the explicit tree structure reference in the stubs to
locate the shims. Instead, it expects that the `SwiftShims` directory
will be added to the header search path.
Most SwiftShims were put in the swift namespace in C++ mode which broke certain things when importing them in a swift file in C++ mode. This was OK when they were only imported as part of the swift runtime but, now they are used in C++ mode both in the swift runtime and when C++ interop is enabled.
This broke when C++ interop was enabled because the `Swift` module contains references to symbols in the SwiftShims headers which are built without C++ interop enabled (no "swift" namespace). But, when C++ interop is enabled, the SwiftShims headers would put everything in the swift namespace meaning the symbols couldn't be found in the global namespace. Then, the compiler would error when trying to deserialize the Swift module.
__swift_size_t on Windows is a size_t, which makes it potentially a
64-bit integer. ULONG, however, is always a 32-bit integer, and so this
cast risks shrinking the apparent size of the cbBuffer argument to
BCryptGenRandom. The effect of that will be to underfill the buffer,
leaving it full of uninitialized memory that we would treat as random.
The actual risk from this in the current implementation is basically
zero, as user code can only ever invoke this with an argument size of 8.
There's no good reason to leave this sharp edge on the API though.
On Windows the filesystem is not case sensitive and this will link just fine.
However, the Windows SDK provides the import library with the lowercase name.
Adjust the name so that the link actually succeeds on case-sensitive file
systems (like on Linux). This fixes the Windows cross-compile.
The system header depends on Windows.h but does not include it itself. This
results in base Windows types (e.g. ULONG) to be undefined. Include the header
to include the needed typedefs.
