Bring back [Explicit Module Builds] Serialize and re-use the inter-module dependency graph as incremental build state

[artemcm]

Second attempt at landing #1230
Which previously caused compiler lit test regressions in main CI.

Building on top of #621, on an incremental build, load a prior dependency graph, check if it is still valid:

• import set of the current module has not changed
• input files of every module in the prior graph are older than the output and if it is, re-use it, skipping invoking the dependency scanner again.

More concretely, computation of the initial incremental state in computeIncrementalStateForPlanning will attempt to read out and validate a prior serialized inter-module dependency graph. If validated, such graph will become a part of the initial incremental state itself.

During build planning, at the stage of computing inter-module dependencies, the dependency scanning action will be skipped if the initial incremental state contains a still-valid prior inter-module dependency graph.

In both cases, if a prior graph is being re-used, or if a new graph was computed via a dependency scanning action, the graph will become a component of the incremental build state to be serialized after the build is complete.

This change does not yet result in skipping the actual module build jobs in the planning output, which can be done with this, but this is left to a followup PR.

There is also some notable overlap between this and what is already done for detecting changes in input files to the current compilation:

• Suppose a Swift module interface of a module dependency has changed. This means that, according to the above mechanism, a dependency scanning action must be performed on an incremental build. This will result in a new dependency graph and a subsequent re-build of the dependency. But, moreover, there is an existing mechanism in place to ensure that source-files also get re-built on changes to previously-recorded inputs to compilation so the source-files will also be re-built when a dependency changes.

Once explicit builds become the default, we can consolidate the two approaches into one.

Partially resolves rdar://66801475

[artemcm]

@swift-ci test

[artemcm]

The original PR removed:

if parsedOptions.hasArgument(.v) {
      try printVersion(outputStream: &stderrStream)
}

from Driver.run. This change wasn't actually related to the PR and was left in it by accident. But this output missing was enough to trip up some lit-tests in the compiler repo...