[6.0🍒][Explicit Module Builds] Cherry-pick Explicit Module Loading fixes and improvements

[artemcm]

Explanation:
This PR is a collection of Explicit Module Build improvements and fixes:

• [DependencyScanning] Treat main source module as a Swift dependency node in cycle resolution graph #72699:
  Otherwise Swift Overlay paths do not get printed for dependency cycles where the sink is the same module as the source module being built.
• [Explicit Module Builds] Only specify '-fmodule-map-file' for bridging header Clang module dependencies #72668:
  Relying on the corresponding field in the '-explicit-swift-module-map-file' provided by the driver.
  • Only bridging headers require a module map because that's what aids header include resolution. With lazy module loading today, '.modulemap' parsing which happens when instantiating Clang is responsible for associating headers with modules. Then upon encountering a header include inside the bridging header the compiler knows which module corresponds to said header and is then able to load explicitly-provided PCM for that module. For all other module dependencies, they are only ever queried by-name from Swift, so '.modulemap' parsing is not necessary.
  • [Dependency Scanning] Add libSwiftScan entrypoint to query binary module dependencies' header inputs' module dependencies
• [Dependency Scanning] By-default do not specify '-fmodule-map-file' inputs on Swift interface dependency compilation jobs #72599:
  Swift interfaces will only ever query module inputs by-name, so parsing modulemap files to resolve their headers is not necessary. The exception to this is textual header ingestion directly into the Swift compiler (ClangImporter). Because then the compiler may need to resolve header includes to the corresponding module (.pcm) inputs. This requires explicitly-specified module maps, until we switch to eager module loading.
  This occurs when there is a a dependency on a binary Swift module, which was built with a bridging header, and this bridging header was serialized into the .swiftmodule and must be ingested by all clients. In this case, we must ensure that all clients of said binary module, direct and transitive, are passed -fmodule-map-file= flags corresponding to dependencies of said header.
• [Explicit Module Build] Do not serialize binary .swiftmodule dependencies when building explicit interface dependencies #72499:
  This operation is not necessary for explicitly-built dependencies and causes redundant filesystem traffic when checking dependency files. With explicit modules, the up-to-date checks on module dependencies are performed by the build-system (Swift Driver).
• [Dependency Scanning] Initialize Swift modules in libSwiftScan on scanner creation #72104:
  Otherwise libSwiftScan clients which rely on EmbeddedSwift feature are not able to execute dependency scans.

Scope: These changes affect dependency scanning and explicit module dependency compilation. While these actions are by-default disabled in swiftc, there are projects that rely on them. swift/72699 is a diagnostic improvement that only affects the code-path triggered on build failure. swift/72104 is an [NFC] change that affects configuration of libSwiftScan to use Swift-written compiler components. swift/72499 is an [NFC] change that disables a redundant operation during explicit module pre-compilation. swift/72599 and swift/72668 reduce the amount of -fmodule-map-file flags passed to explicit module dependency compilation tasks only to the .modulemap files of modules required for header include resolution. This should be a safe change that will only affect projects with bridging headers with their own module dependencies.

Risk: Low. Code-paths disabled by-default and the changes are meant to improve overall soundness and performance of builds.

Testing: Each of the above changes has corresponding test-suite additions.

Reviewed By: @cachemeifyoucan, @eeckstein, @tshortli, @xymus, @nkcsgexi (for various corresponding changes above).

[artemcm]

@swift-ci test