Add system_sysroot to rust_toolchain for pre-installed toolchains

[rejuvenile]

Summary

Adds rust_system_toolchain_repository, a repository rule that discovers a pre-installed Rust toolchain on the system, following the cc_configure pattern from rules_cc.

Problem

When using remote execution with workers that have the Rust toolchain pre-installed, the entire sysroot (~670MB) is transferred as action inputs for every compilation action. This creates significant overhead when the toolchain is already available on the worker.

Solution

A repository rule (rust_system_toolchain_repository) that:

1. Probes the system at fetch time: runs rustc --print sysroot, rustc --version --verbose, rustc --print target-libdir
2. Generates a BUILD.bazel with rust_toolchain() targets where sysroot files are excluded from action inputs
3. Creates symlinks to system binaries (rustc, cargo, rustdoc, clippy-driver)
4. Registers toolchains with proper platform constraints

The rust_toolchain rule gains a sysroot_path string attribute. When set, --sysroot=<path> is passed to rustc and sysroot files are excluded from action inputs.

New files

• rust/private/system_rust_configure.bzl — repository rule + module extension

Modified files

• rust/toolchain.bzl — adds sysroot_path attribute
• rust/private/rustc.bzl — uses system paths when sysroot_path is set
• rust/private/clippy.bzl, rustdoc.bzl, unpretty.bzl — same
• cargo/private/cargo_build_script.bzl — uses system CARGO/RUSTC paths

Usage

# MODULE.bazel
system_rust = use_extension("@rules_rust//rust/private:system_rust_configure.bzl", "system_rust_ext")
system_rust.toolchain(
    exec_triple = "x86_64-unknown-linux-gnu",
    target_triples = ["x86_64-unknown-linux-gnu"],
)
use_repo(system_rust, "system_rust_toolchain")
register_toolchains("@system_rust_toolchain//:all")

This follows the reviewer feedback on #3920 suggesting a repository rule approach similar to @rules_cc//cc/private/toolchain/cc_configure.bzl.

Test plan

• Build with system toolchain on a machine with Rust installed
• Verify sysroot files are not included in action inputs
• Verify remote execution works without toolchain file transfers
• Verify builds still work with the default (non-system) toolchain

[UebelAndre]

Is this needed if you're building the toolchain in a repository rule? Why not symlink the toolchain directory into the repository and wire things up with nominal filegroups?

[rejuvenile]

Is this needed if you're building the toolchain in a repository rule? Why not symlink the toolchain directory into the repository and wire things up with nominal filegroups?

I had a small bias towards not transferring the symlinks during remote execution, but more importantly, I don't how how symlinks would work with sandboxed execution, since they would point outside of the sandbox. With the current approach, Bazel symlinks the toolchain into the sandbox itself.

[UebelAndre]

Then would it be sensible to have wrapper scripts that simply exec out to a hard-coded path on disk? I've seen this pattern in a number of places and haven't noticed a major difference