The _Builtin_float symbols were moved twice, most recently from the OS Darwin library, but previously they were in the embedded @rpath Darwin library. @_originallyDefinedIn doesn't support multiple install names, but it can be replaced with -module-abi-name, and then multiple $ld$previous$ symbols can be used.
Update the Platform and Concurrency magic symbols to use $ld$previous$ everywhere.
rdar://130107191
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).
The install_name trick we are using to make sure that an application
built with a deployment target new enough to *guarantee* that Swift
will be available in the OS (and therefore don't need dylibs bundled)
link directly to /usr/lib/swift/*.dylib, but rewrites the the library
paths to be rpath-relative for older OS's (e.g.,
@rpath/lib/swift/libswiftCore.dylib) doesn't work for sub-minor
version numbers, e.g., the tools can't distinguish between 10.14.4 and
10.14. Therefore, macOS 10.14 is both an "older OS" and a "newer OS".
Hack around the primary problem caused by this---the inability of
first-party Swift programs to launch on macOS 10.14.4---by treating
macOS 10.14 as an "older OS" when building for the Xcode toolchain
(which is used by anyone who will deploy back to an older OS, e.g.,
3rd party applications) but treat it as a "newer OS" when building for
the OS toolchains (which is used when building the OS itself).
Fixes rdar://problem/47007519.
Magic symbols of the form $ld$install_name$os9.0$@rpath/libswiftCore.dylib tell the linker to use that install name when targeting that OS version. Use these symbols to specify an @rpath install name for all back-deployment libraries when targeting watchOS 2.0-5.1, iOS 7.0-12.1, and macOS 10.9-10.14.
rdar://problem/45027809
