Handling Cargo Configurations like RUSTDOC.

[Alexhuszagh]

The following environment variables used to configure cargo aren't trivial to support: they're slightly more complex than just passing them through to the docker container:

• RUSTC
• CARGO_BUILD_RUSTC
• RUSTC_WRAPPER
• CARGO_BUILD_RUSTC_WRAPPER
• RUSTC_WORKSPACE_WRAPPER
• CARGO_BUILD_RUSTC_WORKSPACE_WRAPPER
• RUSTFMT
• RUSTDOC
• CARGO_BUILD_RUSTDOC

For example, RUSTC is an executable, which should be just a different binary to execute. RUSTC_WRAPPER calls RUSTC or rustc, but might be a script or another wrapper (such as sccache around rustc). There's also the issue of host/container architecture/OS mismatch. Our containers assume x86_64-unknown-linux-gnu, but our hosts might be much different.

We've got a few options:

1. Don't support anything except RUSTC, and then only to get the sysroot (it is not passed to the container). Print a warning if any of these environment variables are set.
2. Use these values and don't allow RUSTC to be used for the host except on x86_64-unknown-linux-gnu, and print a warning if the host is not x86_64-unknown-linux-gnu.
3. Just continue to ignore these variables.

Option 1

Print a warning similar to the following:

$ RUSTC=/path/to/rustc cross build ...
Warning: cross does not support the `RUSTC` environment variable: it will be ignored.

Option 2

Mount the parent directory containg RUSTC, for example, and then if the host is not x86_64-unknown-linux-gnu, print:

$ RUSTC=/path/to/rustc cross build ...
Warning: the host is `x86_64-pc-windows-msvc`, but the container expects `x86_64-unknown-linux-gnu` binaries. The executable provided by `RUSTC` may not work as expected.

This might also not work if the script uses data or wraps another executable found outside the directory containing it. There really isn't a good way to handle that, however.

Option 3

Do nothing, keep the current behavior.