Support running `cargo miri` in situations where target != host (e.g. "cross-interpretation")

The playground has the ability to run code under miri, but it would nice to be able to choose other targets.

A somewhat unknown (but highly useful) feature of miri is that it can run as a cross-interpreter. That is, even on x86_64-apple-darwin (or whatever), if I have, say the powerpc-unknown-linux-gnu target installed, I can do:

cargo miri test --target=powerpc-unknown-linux-gnu

and it will simulate running the test on that architecture, including emulating 32-bit big-endian linux (well, the set of linux syscalls that miri supports, anyway).

Right now I can't do this on the playground, and it would be useful to do quick checks and examples of big-endian code.

The downside is needing UI for this, and needing to rustup target add on the playground servers. So I understand some hesitancy.

Personally, I think it's most valuable for targets that are very different than x86_64 — e.g. I feel like just saying having an option for big-endian 32 and 64 bit targets would be good enough.

(It would be nice to also have one for target_pointer_width="16", like msp430-* or avr-*, but these being no_std only, it's hard enough to actually run the code that users probably should just do it locally)

Anyway, I thought I'd mention it. I kind of suspect it's the kind of "that'd be nice but doing it in a non-hacky way is likely not worth the effort" thing, but figured I'd suggest anyway. No worries if you'd rather wontfix this.

Note that this is related to https://github.com/integer32llc/rust-playground/issues/446, but not the same, as --target isn't a RUSTFLAG (or a MIRIFLAG), its a flag for cargo.

Start by reviewing the requested cargo miri test --target=... behavior and the related issue #446. Identify the playground UI and server paths involved in target selection, then determine how supported targets would be installed and executed. Done means users can choose a non-host target and run Miri examples or tests under it.