Rewrite install_name for macOS 10.14 only with the Xcode default toolchain.

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.

Author: DougGregor

stdlib/linker-support/magic-symbols-for-install-name.c

@@ -19,6 +19,7 @@
 
 #if defined(__APPLE__) && defined(__MACH__)
 
+#include <Availability.h>
 #include <TargetConditionals.h>
 #include "../public/SwiftShims/Visibility.h"
 
@@ -77,7 +78,13 @@
   RPATH_INSTALL_NAME_DIRECTIVE(10, 11)
   RPATH_INSTALL_NAME_DIRECTIVE(10, 12)
   RPATH_INSTALL_NAME_DIRECTIVE(10, 13)
+
+  // When building with a deployment target of < macOS 10.14,
+  // treat macOS 10.14 as an "older OS."
+#if __MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_10_14
   RPATH_INSTALL_NAME_DIRECTIVE(10, 14)
+#endif
+
 #else
   #error Unknown target.
 #endif