Allow easier opt-out for `static_libgcc` feature

cc @trybka @armandomontanez

When a rules-based toolchain enables `static_link_cpp_runtimes` (required to use `static_runtime_lib` / `dynamic_runtime_lib`), rules_cc currently also enables `static_libgcc` such that `-static-libgcc` is added to *all* link actions.

This is problematic for toolchains that:
- use clang with `compiler-rt` + `libunwind` (i.e., not GCC’s libgcc for runtime/unwinding), or
- expect a single, process-wide unwinder when DSOs throw/catch across boundaries.

## Current escape hatch

`--features=-static_libgcc` works, but is not ideal for a public/toolchain-default experience.

The alternative option is to **redefine/duplicate** the entire `experimental_replace_legacy_action_config_features` feature set just to drop `//cc/toolchains/args/static_libgcc:feature`.

That duplication is especially painful because some targets aren’t publicly visible, e.g.:
- `:backfill_legacy_args`
- `//cc/toolchains/args/soname_flags:feature`

## Mitigation

I see a few ways to fix this:
1. Gate `static_libgcc` behind an explicit `use_libgcc` flag.
1. Make all targets under `experimental_replace_legacy_action_config_features` public so that opting out for a given toolchain is feasible.
1. Make `static_libgcc` opt-in for rules-based toolchains.

Start by reading the experimental_replace_legacy_action_config_features feature set and the mentioned targets :backfill_legacy_args and //cc/toolchains/args/soname_flags:feature. Compare the proposed ways to let rules-based toolchains avoid //cc/toolchains/args/static_libgcc:feature without duplicating private targets. Done means a supported public opt-out is defined and covered for the affected link actions.

Written by the indexing model from the issue text.