MIR move elimination [6/6]: Miri support

[Amanieu]

Depends on #163335 and #163359

This PR implements the new MIR semantics from rust-lang/rfcs#3943 in Miri.

Notable changes:

• Added a LocalValue::LiveUnallocated state to represent a local that is StorageLive but hasn't been eliminated yet.
• eval_place_for_write will automatically allocate a local if needed.
• Since evaluation of later operands can invalidate earlier operands (due to moves freeing the allocation), eval_operand returns a "snapshot" copy of the operand at the time it was evaluated. This uses a temporary allocation that is freed at the end of the current machine step.
• Move operands with a bare local are evaluated by move_out_local: it snapshots the value and then frees the original allocation, switching the local to LiveUnallocated.
• Calls now follow the evaluation order and behavior specified in the RFC. Tail calls follow the normal operand evaluation order.
• Added EvaluatedRvalue which allows all rvalue operands to be evaluated and snapshotted (if needed) before the destination place of an assignment is evaluated.

[Amanieu]

LLM disclosure: the initial miri support for the new semantics was LLM generated, but I've been iterating on it for a few months now and there is little of that original draft left. LLMs were also used to generate the boilerplate for the Miri pass/fail tests, but each test was manually reviewed and adjusted before committing.

[RalfJung]

The entire point of this function was to carry the common code between tail calls and regular calls. So adding a parameter like this defeats the purpose of having this function in the first place.

This also changes the semantics of move operands for tail calls even without M::move_elimination_semantics. In fact it makes move a complete NOP for tail calls, which IIUC is not what the RFC says.

View changes since the review

[Amanieu]

It doesn't actually change the semantics: we were later forcing FnArg::InPlace into FnArg::Copy for tail calls anyways (in-place doesn't make sense when the stack frame is about to be destroyed).

[RalfJung]

That's a hack with a FIXME. Very different from how the code is presented here.

[rust-bors]

☔ The latest upstream changes (presumably #163783) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.