[rush] Split ProjectChangeAnalyzer, fix build cache hashes

[dmichon-msft]

Summary

Fixes #4400

Makes #3994 more feasible.

Details

Splits the functionality of ProjectChangeAnalyzer into two components:

1. ProjectChangeAnalyzer#_tryGetSnapshotAsync - Performs all the async I/O operations to determine the current state of the repository, including taking a snapshot of process.env so that per-operation hashes can be lazily computed in a stable manner.
2. InputSnapshot - Synchronous data structure representing the state of the repository, which can be queried for operation-level state hashes, or tracked file lists. Performs the evaluation of input/output collisions as part of evaluating said queries. Includes evaluation of incrementalBuildIgnoredGlobs and dependsOnEnvVars, but does not include the hashes from dependencies, since the Operation graph is not provided to this API.

Moves build cache hash computation to the createOperations tap in CacheableOperationPlugin and updates the computation to factor in the runtime operation graph, rather than only the npm dependencies.

For a specific example of how this alters the build cache, consider a repository with one project and two phases in rush build: Project A Phases _phase:first and _phase:second, with _phase:second depends on self: ['_phase:first']

Define a command line parameter --some-flag-for-first that is forwarded only to _phase:first.

Before this change, running rush build and rush build --some-flag-for-first would produce different cache IDs for A (_phase:first), but the same cache id for A (_phase:second).

With this change the cache IDs for A (_phase:second) are also impacted by the presence of the --some-flag-for-first, since it can change the output of A (_phase:first).

How it was tested

For the splitting, added unit tests for InputSnapshot and ProjectChangeAnalyzer#_tryGetSnapshotAsync.

For the build cache IDs, temporarily removed applicability of the --production CLI parameter from _phase:test and validated that running node ./apps/rush/lib/start-dev.js test and node ./apps/rush/lib/start-dev.js test --production still produced different cache keys for _phase:test.

For comparison, validated that the command-line.json alternation and existing rush test and rush test --production had a collision on the cache keys for _phase:test.

Impacted documentation

Any documentation about how build cache keys are computed.