More precise spans for CTFE cycle errors

[RalfJung]

With #72879, CTFE cycle errors lost some of the precision in their span, which was deemed an acceptable consequence of code cleanup. Would be nice to fix that at some point, though.

With our current structure, getting this precision back would be non-trivial, but as a consequence of future cleanup it could become simpler: I have some plans for Allocation API changes, and we might make the methods in memory.rs associated with InterpCx instead of Memory to avoid what is currently a quite annoying split.

[RalfJung]

I tried improving this, but something happens that I do not understand... I added to step this line

self.tcx.span = self.cur_span();

which should mean self.tcx has up-to-date span information on every interpreter step. But this changes nothing about the output of src/test/ui/consts/recursive-zst-static.rs, which is the one that regressed 2 years ago.

I think the problem is that eval_static_initializer only exists on TyCtxt, so this drops the span info, and then calls TyCtxt::eval_to_allocation_raw which uses a DUMMY_SP.
@oli-obk do we need versions of all these functions in queries.rs that take TyCtxtAt so that we can properly preserve the span?

[RalfJung]

do we need versions of all these functions in queries.rs that take TyCtxtAt so that we can properly preserve the span?

Yes, that was it: #97740