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

[artemcm]

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

1. import set of the current module has not changed
2. 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]

This code just moved from Planning.swift it is unchanged.

[artemcm]

This was duplicated in BuildRecordInfo and this instance was not used anywhere.

[artemcm]

Alternatively we can also make this a part of the .swiftdeps file, but for now it seemed simpler to keep it separate.

[artemcm]

@swift-ci test

[artemcm]

I changed this to actually just re-write the file's contents with what they already are, so it actually just updates the timestamp. Previously touch was overwriting file contents with a pre-determined initial state for that input, instead of what the test may have modified it to be at that point.

[nkcsgexi]

Discussed with Artem about this offline. LGTM as the first step for handling incremental explicit module build!

[artemcm]

@swift-ci test

[artemcm]

Thanks @tshortli