feat(config)!: use unqualified names for dir override

[rami3l]

Prepares for #2868.

Previously, when reading from settings.toml, rustup accepts both qualified and unqualified toolchain names for dir overrides, however rustup override set only writes qualified names.

Essentially, this will case the same confusion as we have already had in #3651 where the user might tend to think that they have only pinned the channel with rustup override set nightly, but in reality the host tuple at that time has also been recorded.

This PR ensures the following user journey by mirroring the implementation of #4947:

• The user runs rustup override set nightly.
• The user switches to another default host tuple.
• This override will now qualify the nightly with the new default host tuple.

And the impact analysis from #4947 (comment) still applies, so I'll quote it below:

Impact

Compatibility

This change is breaking exactly because the determination of the default override toolchain will change to reflect the change of the default host tuple.

However, the user can always get the old behavior by specifying the fully qualified name when running rustup default rustup override set (such as rustup default stable-aarch64-apple-darwin rustup override set stable-aarch64-apple-darwin), in the rare case that they would like to decouple the default override toolchain from the default host tuple.

For users with an existing settings.toml, manually running rustup default stable rustup override set stable or similar commands should be necessary for them to get the new behavior.

Performance

As discussed in #4945 (comment), since the default host tuple is resolved at the beginning of rustup's execution, this change has introduced no extra I/O operations, and thus the performance impact is negligible.

PS: This change is also required for rustup toolchain pin to get the right value for dir overrides in #5042. Otherwise, we can only get a fully qualified toolchain name because that's the value it fetches from settings.toml, which means --qualify will behave differently just for dir overrides.

[rami3l]

@djc Would you mind having a look at this? Many thanks :)