[MSYS2] Allow default host triple to be overridden by an environment variable

Problem you are trying to solve

MSYS2 on Windows provides multiple development environments which can share the same $HOME and therefore the same rustup configuration, but which require different Rust host ABIs. For example:

native Windows → x86_64-pc-windows-msvc
UCRT64         → x86_64-pc-windows-gnu
CLANG64        → x86_64-pc-windows-gnullvm

The appropriate host is therefore a property of the current development environment rather than of the user, machine, or project.

At the same time, a project may want to pin its Rust version without pinning its host ABI:

[toolchain]
channel = "1.97"

Ideally, the same project would then resolve that partial toolchain specification according to the active environment:

native Windows → 1.97-x86_64-pc-windows-msvc
UCRT64         → 1.97-x86_64-pc-windows-gnu
CLANG64        → 1.97-x86_64-pc-windows-gnullvm

Rustup already supports this distinction conceptually: an unqualified toolchain such as 1.97 is completed using rustup's default host. However, the default host is persisted in rustup's configuration, so environments sharing the same rustup home cannot have different defaults.

RUSTUP_TOOLCHAIN does not solve the problem because it selects the complete toolchain and overrides rust-toolchain.toml. Using it to select the ABI would therefore also override the project's choice of Rust version.

Separate RUSTUP_HOMEs can provide separate persisted default hosts, but that makes the host choice a property of separate rustup installations. For environments such as MSYS2, the host choice is naturally a property of the currently active shell environment, while the environments otherwise share the same home directory, projects, and installed tooling.

Solution you'd like

Add an environment variable, perhaps RUSTUP_DEFAULT_HOST, which overrides rustup's configured default host when resolving a toolchain specification that does not contain an explicit host.

For example:

export RUSTUP_DEFAULT_HOST=x86_64-pc-windows-gnullvm

combined with:

[toolchain]
channel = "1.97"

would resolve to:

1.97-x86_64-pc-windows-gnullvm

This would allow environments such as MSYS2 UCRT64 and CLANG64 to set their appropriate default host during environment initialization while continuing to share the same RUSTUP_HOME.

The environment variable would affect only resolution of the omitted host component. It would not select or override the channel/version as RUSTUP_TOOLCHAIN does.

Conceptually, host resolution could follow:

explicit host in toolchain specification
    ↓
RUSTUP_DEFAULT_HOST
    ↓
configured default_host_triple
    ↓
normal rustup host detection/defaulting

An explicitly host-qualified toolchain would therefore remain authoritative, while an unqualified toolchain could inherit its host ABI from the current execution environment.

Notes

No response

Start by tracing how rustup resolves unqualified toolchain specifications and how the configured default host is loaded. Check the discussion for existing design constraints, then verify that an environment-provided host affects only unqualified specifications, while explicit hosts and channel selection remain unchanged.