Consider using random keys for incr. comp. hashing

There's been recent discussion about the problems of using unkeyed SipHash128 in the compiler and if that could be exploited by an attacker.

With respect to incremental compilation, it would be possible to generate random keys and cache them together with the dep-graph. These keys could then affect query result fingerprints and dep-node identifiers. Any new from-scratch compilation session would generate new keys, so finding stable collisions should be impossible.

The only downside is that it would be hard to reproduce an actual collision if we ever found one because the keys have to be known for that. However, reproducing collisions that are due to faulty HashStable impls (which is the much more likely case) should be reproducible independent of the keys being used.

Begin with the linked discussion and investigate incremental compilation's dep-graph persistence, query result fingerprints, and dep-node identifiers. No files or tests are named; done means evaluating and implementing a design for random keys that are generated per fresh session and cached with the dep-graph, while preserving reproducibility of faulty HashStable collisions.