When we add the module map describing the compiled module to the command
line, add it to the file dependencies as well.

Discovered while working on reproducers where a command line input was
missing in the captured files as it wasn't considered a dependency.

rdar://164612831

This PR extracts visitation of paths stored in `CompilerInvocation` into
a member function. We already have a second copy of this downstream, and
I'm in the need of adding a third one.

This PR implements `CompilerInstanceWithContext` to improve by-name
dependency queries.

Cases exist where we query the dependency of different names, with
otherwise identical working directory and compile command line inputs.
In these cases, we can create one `CompilerInstance`, whose lifetime is
the same as the dependency scanning worker, and reuse the same compiler
instance to complete the queries. This way we reduce the amount of
header search we need to perform per query, since the already completed
header search results are cached in the compiler instance.

Using a microbenchmark on a prototype of this implementation, we are
seeing a scanning performance improvement of about 20%. The
microbenchmark scans a Swift file that imports everything importable.
When measuring against a set of internal project builds, the geo mean of
total build time improvement is around 1.02x to 1.04x depending on
whether the module caches are populated or not.

Part of work for rdar://136303612.

The driver-generated -cc1 command-lines for C++ named module inputs
introduce some command-line options which affect the canonical module
build command (and therefore the context hash).
This resets those options.

During explicit module build, clear the compilation directory flags when
CWD optimization is on. Now clang CodeGen will not add compilation
directories to DIFile when the corresponding flags are not passed and
make debug info not dependent on CWD.

Clients of the dependency scanning service may need to add dependencies
based on the visibility of importing modules, for example, when
determining whether a Swift overlay dependency should be brought in
based on whether there's a corresponding **visible** clang module for
it.
This patch introduces a new field `VisibleModules` that contains all the
visible top-level modules in a given TU.
Because visibility is determined by which headers or (sub)modules were
imported, and not top-level module dependencies, the scanner now
performs a separate DFS starting from what was directly imported for
this computation.

In my local performance testing, there was no observable performance
impact.

resolves: rdar://151416358

---------

Co-authored-by: Jan Svoboda <jan@svoboda.ai>

Static analysis flagged these cases in which can use std::move and avoid
copies of large objects.

These are identified by misc-include-cleaner.  I've filtered out those
that break builds.  Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.