For cargo build scripts, `AR` uses tool for `ACTION_NAMES.cpp_link_static_library`

In general, build scripts in the cargo ecosystem expect `AR` to accept arguments compatible with `ar`. However on Darwin toolchains it's common to create libraries with `libtool` rather than `ar`.

For example, `apple_support` uses `libtool` for `ACTION_NAMES.cpp_link_static_library`.

In my llvm-based toolchain, I want to use `llvm-libtool-darwin` for `ACTION_NAMES.cpp_link_static_library` for consistency with `apple_support`, but this will cause cargo build scripts to break because they will pick up `llvm-libtool-darwin` for `AR`, ignoring my setting for `ar_executable`. `libtool` does not work if you pass `ar`-style arguments to it. Note that there's a workaround [here](https://github.com/bazelbuild/rules_rust/blob/b6c9468014ffd2acf83faaf6711026d41a21eed5/cargo/cargo_build_script_runner/bin.rs#L137) for `apple_support`, but this doesn't apply to hermetic llvm-based toolchains.

I see this behavior was changed [here](https://github.com/bazelbuild/rules_rust/pull/2675/files) - the old behavior was more convenient for me, because it would allow me to supply an ar-compatible tool in `ar_executable`, while using `llvm-libtool-darwin` for `ACTION_NAMES.cpp_link_static_library`, which is what `apple_support` does.