Upstream Rust tools requiring rustc

Over the last few years I've made some changes that attempt to split the current `rust_toolchain` into multiple toolchains for components that are not typically required for compiling Rust code:
- https://github.com/bazelbuild/rules_rust/pull/1719
- https://github.com/bazelbuild/rules_rust/pull/1641

I'm starting to wonder if this is going against the grain. I'd recently opened https://github.com/bazelbuild/rules_rust/pull/1767 and noticed build failures related to `rustfmt` being unable to locate `librustc-driver.so`
```
(03:52:05) ERROR: /workdir/test/unit/debug_info/BUILD.bazel:4:31: Rustfmt test/unit/debug_info/myrusttest.rustfmt.ok failed: (Exit 127): process_wrapper failed: error executing command (from target //test/unit/debug_info:myrusttest)
(cd /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/ec321eb2cc2d0f8f91b676b6d4c66c29/sandbox/linux-sandbox/494/execroot/rules_rust && \
exec env - \
bazel-out/k8-opt-exec-2B5CBBC6/bin/util/process_wrapper/process_wrapper --touch-file bazel-out/k8-fastbuild/bin/test/unit/debug_info/myrusttest.rustfmt.ok -- external/rustfmt_nightly-2023-01-11__x86_64-unknown-linux-gnu_tools/bin/rustfmt --config-path tools/rustfmt/rustfmt.toml --edition 2018 --check test/unit/debug_info/test.rs)
# Configuration: 362aedf4f02f267774e1298e2f5c5c0104ab07a0e4251fe83fadf56f37f2e212
# Execution platform: @local_config_platform//:host
 
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
external/rustfmt_nightly-2023-01-11__x86_64-unknown-linux-gnu_tools/bin/rustfmt: error while loading shared libraries: librustc_driver-dc7808dac7cc7897.so: cannot open shared object file: No such file or directory
```

I'd noticed in the past that `clippy` also has issues working without `rustc` being installed (not symlinked) relative to the location of the `clippy-driver` binary. While I still think it would be ideal for each tool the Rust org ships (cargo, clippy, rust-analyzer, rustfmt) to exist as it's own toolchain that's only downloaded when needed. There seems to be more reasons to download all tools to one place as more and more things are requiring `rustc`.

That said, I'm wondering if it would make more sense to do away with things like `rustfmt_toolchain` and `rust_analyzer_toolchain` and to instead download all components into one toolchain.

An alternative could be downloading duplicate artifacts, which, in practice, would only result in extracting the same archives into multiple directories. This is something that's already been explored in https://github.com/bazelbuild/rules_rust/pull/1641 by adding `rustc` directly to `rust_analyzer_toolchain_repository` but may not be ideal as now there's a potential for multiple `rustc` binaries with drifting versions.

I'm wondering if other folks have suggestions on how to handle the errors mentioned above and what to do about the Rust org seemingly expanding reliance on `rustc`. I don't necessarily have an issue with that, but want to do what I can to minimize time spent in the analysis phase and ensure no unnecessary inputs are included in `Rustc` actions.

Other related issues:
- https://github.com/bazelbuild/rules_rust/pull/1767
- https://github.com/bazelbuild/rules_rust/pull/1163
- https://github.com/bazelbuild/rules_rust/discussions/815