Make --codegen=linker and --sysroot path-mapping-aware for a cc_toolchain-provided linker

[yakkala-pooja]

Fixes #4250

cc_common.get_tool_for_action() returns the C++ toolchain's linker as a
plain string, and get_memory_inefficient_command_line() returns its link
args (including --sysroot=) as plain strings too. Bazel's path mapping
(--experimental_output_paths=strip) can only rewrite a path that reaches
Args as a File, so a hermetic C++ toolchain whose linker or sysroot is a
generated Bazel artifact ends up with a stale, un-rewritten configuration
segment on the rustc command line, and linking fails when the Rustc action
runs against the stripped bazel-out/cfg layout.

Change

• get_linker_and_args now recovers the backing File for the linker
  (searching cc_toolchain.all_files, including the case where the tool
  lives inside a directory/tree artifact) and threads it through Args
  instead of the raw string, mirroring the map_each/format_each pattern
  already used elsewhere in this file for the Rust toolchain's own sysroot.
• The Rust-toolchain-provided linker (toolchain.linker) already had a File
  on hand for free, so that branch is fixed the same way.
• link_args gets the same treatment for a --sysroot= entry, via a small
  wrapper that leaves every other entry (and any entry that fails to
  resolve) untouched.
• Resolution is skipped up front for any path that doesn't start with
  bazel-out/, since only a generated-artifact path is ever
  configuration-dependent — this keeps the added scan a no-op for the
  common non-hermetic-toolchain case.

Testing

Added test/unit/path_mapped_linker: a minimal cc_toolchain whose linker
and sysroot are genrule outputs (so their real location is genuinely
config-dependent, unlike a normal system toolchain), registered via
--extra_toolchains with linker_preference forced to "cc".

Two things only surfaced against real CI, not local testing:

1. analysis_test_transition refuses to set --experimental_* options, so
   the test can't force --experimental_output_paths=strip on itself. The
   assertions check that --codegen=linker= and the --sysroot= link-arg
   name the right file, not the mapped prefix specifically — this repo's
   own "Path Mapping Linux/RBE/MacOS" CI jobs already run the whole suite
   with that flag set, which is where the stronger check happens.
   Verified manually both ways: normal run passes trivially; with
   --experimental_output_paths=strip on the command line, temporarily
   reverting just the resolution step makes it fail, showing the real
   unmapped configuration segment instead of bazel-out/cfg/, confirmed
   independently for the linker and the sysroot.

2. The fake toolchain, registered via --extra_toolchains with no
   compatibility constraints, was a candidate for every C++ toolchain
   resolution in the build. Under bazel coverage specifically, it was
   getting selected to "link" util/process_wrapper — an unrelated Rust
   tool — and since the fake linker is a no-op script, that build failed
   with "output ... was not created" on both Linux/RBE and macOS CI.
   Fixed by giving fake_cc_toolchain a target_compatible_with constraint
   satisfied only by a dedicated fake_platform, and transitioning
   --platforms to it alongside --extra_toolchains, so the fake toolchain
   only ever matches this test's own configuration. Reproduced locally
   with bazel coverage over this test plus util/process_wrapper together
   and confirmed process_wrapper now falls through to the real toolchain.

Assisted-by: Claude (Anthropic)

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.