The FileCollectorBase is the common interface shared by different
implementations. In lldb, we implement our own lazy variant that allows
us to do the heavy lifting out-of-process instead of inside the signal
handler.
This matches the behavior of the current client (`swift-driver`) and reduces ambiguity in how the nodes in the graph are to be treated. Swift dependencies with a textual interface, for example, must be built into a binary module by clients. Swift dependencies without a textual interface, with only a binary module, are to be used directly, without any up-to-date checks.
Note, this is distinct from Swift dependencies that have a textual interface, for which we also detect potential pre-build binary module candidates. Those are still reported in the `details` field of textual Swift dependencies as `prebuiltModuleCandidates`.
Also perform the plumbing necessary to convince the rest of the compiler that they're just ordinary external dependencies. In particular, we will still emit these depenencies into .d files, and code completion will still index them.
Expand the FrontendOptions to allow the enabling
of the dependency tracker for non-system
dependencies, and switch the previous clients of
`createDependencyTracker` over to using this
option. This ensures that the dependency tracker
is now set only during `CompilerInstance::setup`.
For reproducers in LLDB, we need to collect module dependency
information coming from the clang importer. However, we cannot override
the dependency collector, like we do in LLDB, because its interface is
completely hidden in the clang importer. The solution is to pass the
FileCollector through the DependencyTracker.
(cherry picked from commit c624a87bd5)
