Allow cc_toolchain to declare artifact extensions outside the hardcoded allow-list

### Description of the feature request:

Add a way for `cc_toolchain` configurations to declare `cc_artifact_name_pattern` entries with extensions that are not in `ArtifactCategory.allowedExtensions`, without requiring an upstream patch to `ArtifactCategory.java` for each new extension.

Proposed approach: an opt-in experimental flag (`--experimental_cc_permissive_artifact_extensions`) that, when enabled, skips the validation in `CcToolchainFeaturesLib.java` and uses the toolchain's declared extension as-is. Default off — existing toolchains see no behaviour change.

I have submitted a PR implementing my suggestion, but happy to discuss alternative shapes.

### Which category does this issue belong to?

C++ Rules

### What underlying problem are you trying to solve with this feature?

I work on a Bazel toolchain for a platform whose file extensions are private implementation details under NDA and cannot be disclosed upstream. Declaring those extensions via `cc_artifact_name_pattern` is rejected by the validation against the hardcoded `ArtifactCategory.allowedExtensions`. Adding them to `ArtifactCategory.java` — the usual workaround — is closed to me by the same NDA.

The same gap affects users on public platforms. The allow-list has grown one entry at a time (`.exe`, then `.wasm`), and requests for additional extensions like `.axf` (#5920) have remained open for years.

In my opinion, Bazel shouldn't try to enumerate every possible extension upstream — that's an open-ended task, especially if considering supporting proprietary or domain-specific platforms — and toolchain authors should be trusted to declare what's valid for their own toolchain

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

Windows

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

release 9.1.0

### 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
https://github.com/bazelbuild/bazel.git
78f6b47fdcb08909fa35d68e5eabe5ecebe72b97
```

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

- #5920 — request to add .axf for ARM cross-compilation; open since 2018, maintainer offered to accept a patch but the contribution never landed.
- #17117 — umbrella: file types should come from the toolchain rather than being hardcoded. Referenced from the Bazel team's own TODO at CppFileTypes.java:241.
- Past addition of .wasm to the same enum: same pattern as #5920, addressed as a one-off.

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

_No response_

Start with CcToolchainFeaturesLib.java to trace validation of cc_artifact_name_pattern entries against ArtifactCategory.allowedExtensions. Review the related context in ArtifactCategory.java and the TODO at CppFileTypes.java:241. Done means an experimental flag permits declared extensions when enabled while preserving current validation by default.

Written by the indexing model from the issue text.