cargo-miri: ensure all rustc invocations go via our wrapper

[RalfJung]

If we would set RUSTC to something like /cargo-miri-phase-rustc/if-you-see-this-some-build-script-forgot-to-apply-the-rustc-wrapper, then it would be blindingly obvious if anything ever bypassed our RUSTC_WRAPPER and called rustc directly. This kind of bypass is something we don't want to happen as then we can't carefully adjust the command-line flags to make everything work with Miri.

Unfortunately, this is currently blocked:

• autocfg: autocfg still calls rustc without the wrapper cuviper/autocfg#58
• eyre: build.rs probe fails to propagate --target and does not use RUSTC_WRAPPER eyre-rs/eyre#84
• cargo itself: RUSTC_WRAPPER is ignored for rustc -vV call cargo#10885

[RalfJung]

rust-lang/cargo#10885 has a proposed fix at rust-lang/cargo#13659, but that needs testing to ensure that this doesn't break various ways of using cargo. Help wanted, in particular if you have experience with sccache :)

[RalfJung]

FWIW the eyre issue is not necessarily a blocker; eyre will simply fail to build the probe and then disable both backtrace and track_caller, but other than that things will still work.

[RalfJung]

Turns out there's a huge amount of build scripts out there that invoke RUSTC without caring about RUSTC_WRAPPER. So it's likely people will run into a bunch of build failures if Miri decides to enforce the use of the wrapper.

We can either see this as a chance to push the ecosystem towards respecting the wrapper, or as an argument against setting RUSTC to a non-existent path...

A backup plan may be to keep setting RUSTC to the miri binary and set MIRI_BE_RUSTC to host. That is at least coherent in the sense that the default sysroot of the binary will also be a host sysroot. This will work fine as long as all these scripts do is query the version number. Build probes will fail in cross-target interpretation. It seems fine to me to say that this is a bug in the respective build probe, Miri's cross-target interpretation requires the wrapper to be used.
(That's what #3411 already does.)

[RalfJung]

A backup plan may be to keep setting RUSTC to the miri binary and set MIRI_BE_RUSTC to host.

That's what we are doing now, and it seems to be the best we can do.