Tracking: `settings.toml` and its stability guarantees

I am bringing this up because of @djc's point that introducing too many environment variables for configuration might be too noisy: https://github.com/rust-lang/rustup/pull/4869#discussion_r3505609072

It seems that, following cargo's convention, a lot of cargo's config should have env var counterparts. Should rustup move more or less towards that direction?

Also there has been a previous topic regarding Nix-generated settings.toml in https://github.com/rust-lang/rustup/issues/4167, the question is whether we should stabilize at least a part of this config.

For now I have this on my machine:

version = "12"
default_toolchain = "stable-aarch64-apple-darwin"
profile = "default"
auto_install = "disable"

[overrides]

... but it's not entirely clear if this config should change much (and thus can be backed up/generated by a dotfile manager like chezmoi/Nix) and if so under what circumstances. Using rustup default to change the settings might look surprising because one may expect that only rustup set can change it.

Now that we have state.toml maybe we can move some values over there.

Start by reviewing the existing settings.toml and state.toml formats and the behavior of the rustup default and rustup set commands. Compare the proposed environment-variable convention with Cargo's configuration, then determine which settings should be stable and where they belong. Done requires an agreed configuration boundary and documented behavior.