Miri: refactor handling of "uncanonical" AllocIds

[RalfJung]

There are (at least) two situations where Miri uses a different AllocId for allocations than would be used in already created "global" allocations:

• extern static are supported by mapping them to another, existing allocation.
• TLS statics need a different AllocId for each thread.

Currently both of these use different systems, and the extern static system has some disadvantages like not erroring on this program:

extern {
    static mut TEST: i32;
}

fn main() {
    let _x = unsafe { &TEST };
}

We should use the same system for both, and that system should be to do whatever adjustments we need to do when converting Pointer<()> (an untagged pointer, in global tcx memory) to Pointer<M::PointerTag>.

With #70685 resolved we might not need this for TLS statics any more, depending on the solution. But it would still be good to do this for extern static. Either way, as part of this we should also cleanup the TLS static handling in Miri, which currently special-cases ConstValue::Scalar being converted into Miri machine values -- we should do the right thing for all pointers in constants/globals.

Cc @oli-obk

[RalfJung]

Also I noted const_eval and eval_const_to_op are somewhat confusingly named in Miri. And const_eval has a suboptimal interface; @oli-obk can we avoid having to pass the ty and somehow compute that from the gid?

[RalfJung]

Also I wonder what it would take to avoid layering violations like https://github.com/rust-lang/miri/pull/1284/files#r409513235 (Cc @vakaras). Maybe Miri's const_eval should not already do eval_const_to_op (then it would not need a ty any more either) and instead return both a ConstValue and the AllocId backing that value (and that AllocId would be guaranteed to be a GlobalAlloc::Memory in tcx.alloc_map)?

Also proposed new name for eval_const_to_op would be just const_to_op... this function, conceptually, is more conversion than evaluation; the fact that it has to evaluate anything is just due to the lazy nature of rustc's query system. That is unlike, e.g., eval_place_to_op with evaluates a mir::Place to an interpret::Place.

[oli-obk]

Also I noted const_eval and eval_const_to_op are somewhat confusingly named in Miri. And const_eval has a suboptimal interface; @oli-obk can we avoid having to pass the ty and somehow compute that from the gid?

we can (tcx.type_of + substituting), but that may be expensive.