The CxxStdlib module now relies on the libcxxshim modulemap, so we
need to make sure that the modulemap is copied into the correct location before CxxStdlib is built.
rdar://108007693
Cxx & CxxStdlib modules are Swift-only, they do not require invoking clang directly.
When building with `SWIFT_INCLUDE_TOOLS=NO`, Clang is not available as a CMake target (see `swift_common_standalone_build_config`).
rdar://107780733
Instead of a dynamic `swiftCxx.dylib` library, let's build a static library to simplify backdeployment and reduce potential compatibility difficulties in the future.
This also adds `NO_LINK_NAME` option to `add_swift_target_library` to prevent the CMake scripts from passing `-module-link-name` to swiftc when building a given module. This fixes linker errors, which would otherwise occur due to the force-load symbol name (`_swift_FORCE_LOAD_$xyz`) being emitted for the libraries that are now static (`swiftCxx`, `swiftstd`).
Allow Linux distributions to provide their own C++ flags to compile the
C++ overlay correctly. The default is kept the same for Ubuntu and
CentOS, but other distributions can provide other flags to use their own
distro GCC stdlibc++ or even libc++ if they choose.
This should not change the current compilation, but opens the door for
other maintainers to provide a different value that work on their
systems.
This allows projects that don't want to pull in the entire C++ standard library to use stdlib-independent C++ interop utilities like `CxxSequence`.
This also makes the utilities available on platforms where we don't currently have the `std` overlay available, e.g. Windows.