Estimate file versions safely

[pepeiborra]

For a long time, defineEarlyCutoff has been accessing the Values store directly
to compute GetModificationTime values instead of calling use, breaking the
invariant. The values are used to associate the rule result to a file version,
which gets recorded in the Value as well as used as the key in the Diagnostics
store.

The problem here is that the GetModificationTime rule computes a new version and
mutates the Values store, so if defineEarlyCutoff peeks in the store before
GetModificationTime has run, it will grab the old version. This leads to lost
diagnostics and potentially to misversioned Values.

Fixing the problem is tricky, because we cannot simply use GetModificationTime
inside defineEarlyCutoff for all rules. There are three issues with this:

1. Creating a dependency on GetModificationTime: if everything depends on it,
   then we lose the ability to do early cutoff
2. Creating cycles in the build graph, since GetModificationTime has
   dependencies itself. Because hls-graph doesn't implement cycle detection (Shake
   did), it is a nightmare to debug these cycles.
3. Creating overhead, since GetModificationTime calls the file system for non
   FOIs and in the past this was very expensive for projects with large cartesian
   product of module paths and source folders

To work around these I had to introduce a new hls-graph primitive,
applyWithoutDependency, as well as add a bunch more fragile type tests on the key
type to decide on whether to use GetModificationTime or peek into the values
store. The type casts could be cleaned up by introducing a type class, but I'm
not sure the end result would be any better.

To understand the issue and debug the implementation of the fix, I added a
number of opentelemety traces which I'm leaving in place in case they could be
useful in the future.

[michaelpj]

It would be nice if the excellent description of the problem and the solution was recorded somewhere more durable!