Ship Miri on stable toolchains

[RalfJung]

@shepmaster suggested we should ship Miri on stable, and the general reception was positive. What needs to be done to make that happen?

• [ ] Figure out the process. Which teams even need to be involved? Probably the compiler team, primarily. And the release team to update the release machinery?
• [ ] Update docs where needed. The README still calls Miri an "experimental interpreter", which does not sound right for a tool shipped on stable.
• [ ] Make sure -Zmiri flags cannot be used on stable. We're "parsing" these very early in the Miri binary, can we even figure out at that moment whether we are on stable yet?
• [ ] Decide which of the -Zmiri flags we want to expose on stable, and how. Just make them -Cmiri? Or is there something better?
• [ ] Make the magic miri_* extern functions not available on stable. Can we somehow require that the crate calling them must have a particular feature gate or so?
• [ ] On stable, either skip doctests or figure out if we can still somehow use --runtool and --test-builder.
• [ ] The Miri driver currently passes some flags to rustc to change the configuration a bit. Most of these are unstable so this strategy does not work on stable. Instead we should programmatically change the flags so we don't have to go through argument parsing and can bypass the stability check.
• [ ] Does the way we build the sysroot even work on stable? We'd have to set RUSTC_BOOTSTRAP; that requires t-compiler approval.
• [ ] Anything else that I missed?

[RossSmyth]

I think a good way to go about the flags would be to do something similar to the other Rust tools. That is to have a toml file for setting config options. I would make it similar to the relationship of cargo and rustc, and only have the toml file read when cargo-miri is used, then also have the -C flags available as well through the miri binary & MIRIFLAGS.

Whether that is miri's own custom toml, or a new table of the cargo.toml (like #2451) I'm not sure.

[RalfJung]

Being able to set Miri's flags from a config file is tracked at https://github.com/rust-lang/miri/issues/2347; I don't think this is blocking or blocked on stabilization. We only have to figure out the names for the flags understood by miri itself here; support in cargo-miri can come later IMO.

[RalfJung]

We are using rustdoc -Zunstable-options to make doctests work (specifically we need --runtool and --test-builder). So it looks like currently, on stable cargo miri would have to skip doctests.