We cannot link against the DSO (dll) on Windows and instead link against
the import library. Let the driver understand this and use the standard
linking technique. Adjust the name of the emitted files accordingly and
use the `%target-library-name` macro more freely.
Two tests remain:
- multifile.protocol-conformance-member
The getter is synthesized by not exported so `llvm-nm` is unable to
see it
- multifile.nested_types
Windows uses the singleton strategy, so the emitted full type
metadata does not have the reference to the value witness table for
Void
The naming convention is different on Windows than on Unix-like
environments. In order to follow the convention we need to substitute
the prefix and the suffix. Take the opportunity to rename the
`target-dylib-extension` to the CMake-like variable
`target-shared-library-suffix` and introduce
`target-shared-library-prefix`. This helps linking the test suite
binaries on Windows.
Consider a module with two files, one of which references a
function in the other file. If the function had PublicNonABI
linkage, the forward reference has HiddenExternal linkage.
If we saw the forward reference first in the merge modules
process, we would not update the linkage of the function
when we later deserialized its body.
This would result in it being dropped from the final merged
SIL module. Previously this did not cause any problems
because all inlineable functions had public linkage, but now
that default argument generators no longer have public entry
points, this could cause linker errors.
