In LLVM unified builds `%swift_obj_root` points to `<LLVM build dir>/tools/swift`,
and folders like `bin`, `lib` and `share` are not under `swift_obj_root`, which
makes some tests fail.
For the cases in which `%swift_obj_root/lib` was used, replace it by
using `%swift-lib-dir` instead. Replicate `%swift-lib-dir` to create
`%swift-bin-dir` and `%swift-share-dir`, and use those instead of
`%swift_obj_root/bin` and `%swift_obj_root/share`.
This alternates work both in Swift build-script builds and also in LLVM
unified builds.
This will mean that '-disable-implicit-swift-modules' also automatically implies two things:
1. Clang modules must also be explicit, and the importer's clang instance will get '-fno-implicit-modules' and '-fno-implicit-module-maps'
2. The importer's clang instance will no longer get a '-fmodules-cache-path=', since it is not needed in explicit builds
Since https://github.com/apple/swift/pull/63178 added support for Clang modules in the explicit module map, it is possible for there to be multiple modules with the same name: a Swift module and a Clang module. The current parsing logic just overwrites the corresponding entry module in a hashmap so we always only preserved the module that comes last, with the same name.
This change separates the parsing of the modulemap JSON file to produce a separate Swift module map and Clang module map. The Swift one is used by the 'ExplicitSwiftModuleLoader', as before, and the Clang one is only used to populate the ClangArgs with the requried -fmodule-... flags.
This lets users of `-explicit-swift-module-map-file` use a single mapping
for all module dependencies, regardless of whether they're Swift or Clang
modules, instead of manually splitting them among this file and command
line flags.
