This avoids a decent number of allocations, enough to speed up
incremental runs of many rustc-benchmarks, the best by 2%.

Fixes #50501

Fixes #47326

incr.comp.: Load diagnostics from previous session lazily and clean up on-disk-cache persistence code.

Part of #45873

incr.comp.: Make DefSpan an input dep-node so it is not affected by the existing Span/HIR hashing hack.

Part of #45238

This commit moves compression of the bytecode from the `link` module to the
`write` module, namely allowing it to be (a) cached by incremental compilation
and (b) produced in parallel. The parallelization may show up as some nice wins
during normal compilation and the caching in incremental mode should be
beneficial for incremental compiles! (no more need to recompress the entire
crate's bitcode on all builds)

This should limit the availability of `try_mark_green_and_read` making
it harder to abuse.

There was a bit of code shared between `try_get_with` and `ensure`, after I
added `ensure`. I refactored that shared code into a query-agnostic method
called `read_node_index`.

The new method `read_node_index` will attempt to find the node
index (`DepNodeIndex`) of a query. When `read_node_index` finds the
`DepNodeIndex`, it marks the current query as a reader of the node it's
requesting the index of.

This is used by `try_get_with` and `ensure` as it elides the unimportant (to
them) details of if the query is invalidated by previous changed computation (Red)
or new and if they had to mark the query green. For both `try_get_with` and
`ensure`, they just need to know if they can lookup the results or have to
reevaluate.