[Don't merge] RAR cache file optimization

[ladipro]

Attempts to fix #8635

Context

The per-project RAR cache is always read from disk and deserialized prior to actual RAR execution. This is wasteful in situations when we already have all required data in memory - when RAR is hosted in a long-running process like MSBuild server or out-of-proc node. This PR attempts to implement a mechanism by which the load could be avoided, while maintaining the guarantee that the cache file has well-defined contents after RAR is done.

Changes Made

• Made loading of the cache file lazy/on demand. If everything is satisfied from the process-wide cache, the file is not loaded. When the file is loaded, its contents are merged with what we've calculated to be the per-project cached data so far.
• Made saving of the cache file conditional as well, by following an elaborate scheme. We cache metadata about the file in memory to decide if it should be saved after RAR has done executing.

Testing

• Functional: Verified that when building with MSBuild server enabled and /m:1, in large solutions like OrchardCore zero loads and saves of cache files occur in incremental builds. Everything is satisfied from memory.
• Performance: Measured the wall clock time savings in incremental build compared to baseline. Even with the baseline being larger cache files without Don't save data on immutable files to per-project disk cache #8802, the best I could get was ~5% faster RAR.

Notes

I am opening the PR for posterity but the impact is currently not high enough to justify the churn and added complexity. The 5% cited above is achievable only in very special cases like server + /m:1. In real-world parallel builds, due to non-deterministic scheduling of projects to nodes, it takes a very long time for all nodes to get warmed up to the point where most cache loads can actually be avoided.

We could do better if we loosen up the requirements for saves (see this comment) but I'm afraid that would come back to bite us in the future.