Support virtual toolchains to "mix and match" components

[rami3l]

Motivation

There has been repeated requests about overriding specific components of a toolchain while keeping others intact:

(Or maybe we just don't have to be so strict about what "required" means and just allow people to mix and match components in ways that break).
@brson in #298 (comment)

I'd like to install https://xous.xobs.io/dist/rust-std-1.91.0-riscv32imac-unknown-xous-elf.tar.gz or https://xous.xobs.io/dist/rust-std-1.91.0-riscv32imac-unknown-xous-elf.tar.xz with rustup.
@xobs in #4635 (comment)

My team prefers cargo +nightly fmt for formatting over stable.
@Sajjon in #4391

one wants to use nightly features from rustfmt, while also keeping a stable version for builds + deploys
@CinchBlue in #3546

I think using nightly rustfmt together with stable rust is perfectly valid, so i was thinking about something along the lines of

[toolchain]
channel = "stable" # this is essentially the default toolchain

# channel for this component isn't specified, will use stable
[[toolchain.components]]
name = "clippy"

# channel is nightly, so nightly rust will be used for this component
[[toolchain.components]]
name = "rustfmt"
channel = "nightly"

@ghost in #3546 (comment)

Feasibility

This shouldn't be technically difficult to add in rustup, and @lynzrand has implemented exactly that in https://github.com/lynzrand/lunik, allowing the existence of overrides like the following (in a user-wide config):

{
  "toolchain": {
    "stable": {},
    "dev": {
      "fallback": "stable",
      "override": {
        "moon": "/home/rynco/.cargo/bin/moon"
      }
    }
  },
  ...
}

Also, as very well demonstrated in the above example, a special name must be assigned to the new virtual toolchain, which must not be confounded with its parents.

Challenges

• One issue that I've had using lunik is that sometimes components from another toolchain might have compatibility issues with the current toolchain. To mitigate this situation, we have to at least properly inform the relevant users of this fact and help them diagnose issues related to this usage.

• Another issue would be determining the scope of this new configuration option. Should this be project-wide, user-wide, or a full-fledged layered configuration system is required like with toolchain overrides? If a fully-layered implementation is required, wouldn't that cause problems regarding toolchain name shadowing?

• Some operations are simply banned from virtual toolchains, such as the additional installation of components. Fortunately, this is the same for linked toolchains (e.g. system) so we should be able to handle the current case similarly.

• Should we just forward the binaries while keeping little traces of this virtual toolchain on disk, or should we do links to existing toolchains to provide better flexibility beyond the binary invocations? For example, Support installing third-party tier-3 target support with rustup #4635 wants to inject support libraries into the toolchain installation.