The intent is two-fold:
1. This fixes a bug where we would only attempt to resolve direct dependencies as Clang modules for Swift Binary modules.
2. Ensures that we only query the presence of a Bridging Header for textual Swift modules.
Resolves rdar://73015075
This speeds up contexts where we need to resolve dependencies after the main scanning action is complete.
For example: libSwiftScan binary graph generation and cycle detection.
This is necessary because ordinarily, ModuleDependenciesCache must be queried on a per-loader basis.
For example, we first search for Swift modules with the SerializedModuleLoaderBase, at which point we check the cache for previously-found Swift modules. If cache is not hit, we search the filesystem.
Then we search for Clang moduels with the ClangLoader, at which point we check the cache for previously-found Clang modules. If cache is not hit, we search the filesystem.
This change allows to eliminate a bunch of filesystem searching in step (1) when we know we have completed the scan and no longer need to be concerned with the correctness of the cache contents.
Adds a C API layer consisting of:
- Data structures used to represent in-memory result of dependency scanning
- Opaque dependency scanner tool (C wrapper for `DependencyScanningTool`)
Refactors `ScanDependencies.cpp` to produce dependency scanning result in the form of the above binary format.
This commit refactors ScanDependencies.cpp to split the functionality into two functional groups:
- Scan execution code that performs the mechanics of the scan and produces an in-memory result
- Dependency scanner entry-points used when the scanning action is invoked as a `swift-frontend` execution mode
This commit also adds the aforementioned in-memory dependency scanning result in `FullDependencies.h`, modeled after the InterModuleDependencyGraph representation in swift-driver
