supports_dynamic_linker_feature is overloaded and prevents depending on dynamic libraries more than it should

### Description of the bug:

See https://bazelbuild.slack.com/archives/CGA9QFQ8H/p1741216687826279 for more context

https://github.com/matt-sm/cmake-ctest has a repro

If you try to build `//:hello_bin_shared` on macOS, you end up statically linking `libhello.a` instead of dynamically linking `libhello.dylib` as would be expected by the `linkstatic = False` on the bianry.

This is because [this check](https://github.com/bazelbuild/bazel/blob/16305467290fe06baa15f37d75a04bd156a4b9b8/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLinkingHelper.java#L933) replaces the correctly chosen dynamic dependency with a static one, because [the `supports_dynamic_linker_feature`](https://github.com/bazelbuild/rules_cc/blob/ef3c571d8d8c7038bc28fcddced8749bb6c5d6e7/cc/private/toolchain/unix_cc_toolchain_config.bzl#L587) is not added to the default macOS toolchain.

This is not the intention of this feature - per [the Slack thread](https://bazelbuild.slack.com/archives/CGA9QFQ8H/p1741216687826279) the goal of this feature is to constrain the production of nodeps dynamic libraries, but consumption of dynamic libraries.

@fmeum suggested we may need to split this feature into two - one for nodeps dynamic libraries (the current intended functionality) and one for consumption of dynamic libraries (which should be enabled by default on ~all platforms).

I'm not so sure - I don't see a place where we'd want to disable consuming dynamic libraries and _also_ support `linkstatic = False`, so I'd be tempted to just remove or further specialise [the overriding conditional](https://github.com/bazelbuild/bazel/blob/16305467290fe06baa15f37d75a04bd156a4b9b8/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLinkingHelper.java#L933).

### Which category does this issue belong to?

C++ Rules

### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

On macOS clone https://github.com/matt-sm/cmake-ctest

bazel build //:hello_bin_shared

otool -L bazel-bin/hello_bin_shared

Expect to see an entry like `@rpath/libhello.dylib` indicating a dynamic dependency on `libhello.dylib`, but don't see one because it's statically linked.

### Which operating system are you running Bazel on?

macOS

### What is the output of `bazel info release`?

release 8.1.1

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse HEAD` ?

```text
git@github.com:matt-sm/cmake-ctest.git
9c6c013b0134ec7a9094203fe0649c8fa58c31dd
```

### If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

_No response_

### Have you found anything relevant by searching the web?

_No response_

### Any other information, logs, or outputs that you want to share?

cc @keith

Reproduce the issue with `bazel build //:hello_bin_shared` in the linked `matt-sm/cmake-ctest` repository and inspect the result with `otool -L`. Read the conditional in `src/main/java/com/google/devtools/build/lib/rules/cpp/CcLinkingHelper.java` together with `cc/private/toolchain/unix_cc_toolchain_config.bzl`; done means macOS consumes `libhello.dylib` for `linkstatic = False` without breaking the intended nodeps dynamic-library constraint.

Written by the indexing model from the issue text.