[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#_tryGetSnapshotProviderAsync - 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. InputsSnapshot - 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 beforeExecuteOperations 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).

Added a new flag enabled to Operation to control whether or not a given operation in the graph should be executed. Updated graph construction to use this flag for operations that are dependencies of the user's selection, but not directly included (e.g. when using --only or --impacted-by), or during watch-mode incremental builds.

Added a new property cacheHashSalt to build-cache.json to allow repository maintainers to globally force cache misses if they have altered the build process in a way that Rush can't currently detect, for example if Rush plugins emit files that would be picked up by the cache.

How it was tested

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

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.

Validated cache reads/writes using the heft-node-everything-test project. Confirmed that cache is not written during a rush rebuild -o, but can be read during rush build -o. Confirmed that cache reads can occur during rush start -o, even on subsequent iterations that leverage the new :incremental suffixed scripts.

Validate the cacheHashSalt property by setting the salt to different values and validating cache/miss hit depending on whether or not a prior build had happened with the same salt.

Impacted documentation

Any documentation about how build cache keys are computed.

[D4N14L]

We should do a pre-publish to verify that everything that is changing here doesn't break our flow, since we're very likely the largest customer on this tool.

[dmichon-msft]

Addressed feedback.