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 recovers the backing File for the linker (searching
  cc_toolchain.all_files for the string cc_common.get_tool_for_action()
  returned, including when 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.
• An exact match is tried first; a fallback matches on the part of the
  path after bazel-out//bin/ instead, for a Bazel version where
  cc_toolchain's own files are reported under a different configuration
  segment than get_tool_for_action()'s string for the very same toolchain.
  The matched File's own path is always used to render the flag, so
  whichever configuration Bazel actually materializes it under is what
  ends up on the command line.
• 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 scan a no-op for the common
  non-hermetic-toolchain case.
• construct_arguments tracks the File(s) it resolved on the returned args
  struct as extra_action_inputs, and rustc_compile_action merges that into
  the Rustc/RustcMetadata actions' inputs, since passing a File through
  Args doesn't by itself register it as an action input. Both this and
  the config-agnostic fallback above only trigger when a resolution
  actually needed them, so the exact-match path (sufficient on most Bazel
  versions) pays no extra cost.

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" and scoped to
this test's own configuration via a dedicated platform +
target_compatible_with, so it can't be picked up by unrelated builds
elsewhere in the graph.

The assertions check that --codegen=linker= and the --sysroot= link-arg
name the right file. They don't check the mapped bazel-out/cfg/... prefix
directly, since a test can't force --experimental_output_paths=strip on
itself — this repo's own "Path Mapping Linux/RBE/MacOS" CI jobs already
run the whole suite with that flag set, which is where that stronger
check happens.

Verified against this repo's full CI matrix — Ubuntu, RBE, macOS ARM64,
Windows, and every supported Bazel version down to the minimum (7.4.1) —
all green. Also verified locally: the assertions fail as expected when
the resolution logic is temporarily reverted (both for the linker and the
sysroot), and the fake linker's argument parsing was checked directly in
isolation.

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.