64-bit Windows defines both _WIN64 and _WIN32, so the logic here would
always end up defining 32-bit C types for Swift's `Int` and `UInt`.
Fix the ordering to check for 64-bit first, then 32-bit second.
Note that the SwiftShims version of this code has always been wrong,
but it's completely benign because SwiftShims is only used in the
Swift runtime itself, which is built with Clang (on all platforms),
and doesn't need to go through this code path. Still, we fix it in both
places, so we don't get a nasty surprise if the SwiftShims version of
the header later gets included in a non-Clang C++ compiler.
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
