Allow using swiftc as the Swift Build linker driver

[owenv]

Swift Build currently always uses clang as the linker driver, while SwiftPM has historically used swiftc. We should add a build setting clients can use to opt into using swiftc as the linker driver to ensure consistency where the two drivers have divergent behavior / command line flags. This will likely require some changes throughout the build system where we currently make assumptions about flags the linker driver accepts, and especially how we escape flags to pass them to the underlying linker.

[jakepetroules]

My thinking for a strategy that could make sense here as a reasonable behavior across all platforms is, for a given module:

• If using any Swift translation units, use swift-as-ld
• else if using any C++ or ObjC++ TUs, use clang++-as-ld
• else if using any C or ObjC TUs, use clang-as-ld
• else (e.g. pure asm), use ld

Not sure how we could generalize that to other languages we may want to support in the future.

[compnerd]

@jakepetroules I think that we should continue to use clang as the linker driver for the ASM case. However, the important thing is the middle two cases you identified - the failure of SPM to do so has been the reason that we need to overlink on Windows and explicitly link the swift standard library on all targets as swiftc will force the dependency on the swift standard library.

[jakepetroules]

Why clang for the pure ASM case? Wouldn't that potentially pull in unexpected dependencies?

[compnerd]

It is actually the inverse - it drops unnecessary dependencies - use of swiftc would pull in the swift standard library.

[jakepetroules]

Sorry, I meant why use clang instead of ld for the pure ASM case? Wouldn't that pull in libc when you might not want it?