make incremental ICEs more informative

[matthiaskrgr]

We are getting a couple of "compiler crashed spuriously due to incr comp, not reproducible" ICEs every week for years now.
https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AA-incr-comp

I wonder if we can print more data during/before the ice, if it occurs, to help us track down what the actual problem is.
So far the various stacktraces have not been too helpful without a clear reproducer afaik.
A similar approach made for a parallel compiler deadlock had great success #118169

[bjorn3]

To take a random incr comp ice (#118007), I don't think there is much we can do to make it more informative. The issue here is exactly that rustc doesn't have enough knowledge to turn the fingerprint 7290871ab612167b-16c2654baa403be5 back into a DefId for which we could print something human readable. And for another (#117665) the newly computed query result was different from the cached version even though all deps are identical. We can and do show the newly computed result, but the old result isn't stored anywhere. Only the fingerprint of the result is stored in the query cache. In fact for this specific query we don't even permanently store the result during the current compilation session. It is stolen by one of the passes that transforms MIR before MIR optimization.

In both cases it is likely that we are forgetting to track some state that influences the query result.

And finally for #114640 there is already a PR open to fix it (#109050, but no agreement about if it is the right way to fix it from what I can tell.

There could be incr comp issues where more informative ICE messages are informative though. I haven't looked through the entire list of incr comp issues.