Cache codegen of Spans

[AlexanderPortland]

Profiling showed that codegen_span_stable was a significant bottleneck for Kani, as it has to do all the queries to rustc_public and logic to construct a Location for a given Span. However, I tested and found that the function was typically being called multiple (~500) times on the exact same Span throughout an execution.

This PR introduces a new cache to store the result of those calculations for future use.

Since the key to this cache is a rustc_public::Span, it's dependent on the type being Hash, something which will hopefully be implemented in rust-lang/rust#145018. For now, I've tested the change using a hacky transmute to implement Hash myself.

Results

Caching span codegen led to a nice 9.4% reduction in the end to end compilation of the standard library (@ commit 177d0fd, assuming #4276 lands).

Like #4276, this is a caching change and will have an associated memory overhead. Based on the max capacity of the map during execution, I estimate its peak size to be ~4.4MB when run on the standard library, which is around 0.13%-0.17% of Kani's total memory usage on the same run. This seems acceptable for the measured performance benefit.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

[AlexanderPortland]

This change is superseded by #4313, which caches Span codegen in a more systematic way while also caching other kinds of codegen.