Allow generated directories in `cc_tool.allowlist_include_directories`

### Description of the feature request:

I'm trying to use the [WASI SDK](https://github.com/WebAssembly/wasi-sdk) to create a CC toolchain. The pre-built release archives on GitHub include a directory with all the system header files (`lib/clang/19/include/`), but I can't figure out how to add them to the toolchain with [`allowlist_include_directories`](https://github.com/bazelbuild/rules_cc/blob/0.1.1/cc/toolchains/tool.bzl#L83) in `cc_tool` because Bazel insists that the directory prefixes must be absolute.

The setup looks something like this (see the `git remote get-url origin; git rev-parse HEAD` answer for a complete repro):

`MODULE.bazel`:

```starlark
# ...

http_archive(
name = "wasi-sdk-x86_64-linux",
build_file_content = """
load("@bazel_skylib//rules/directory:directory.bzl", "directory")
load("@bazel_skylib//rules/directory:subdirectory.bzl", "subdirectory")

package(default_visibility=["//visibility:public"])

alias(name = "clang", actual = "wasi-sdk-25.0-x86_64-linux/bin/clang")
alias(name = "lld", actual = "wasi-sdk-25.0-x86_64-linux/bin/lld")

# ...

directory(
name = "all-files",
srcs = glob(["wasi-sdk-25.0-x86_64-linux/lib/**"]),
)
subdirectory(
name = "include",
parent = ":lib",
path = "wasi-sdk-25.0-x86_64-linux/lib/clang/19/include",
)
""",
integrity = "sha384-2hliAV3H1pxMMROU9BarleLEH0dng/XdvfpSsGJKbvRvyy98K59WD8fN5RrvaCML",
url = "https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-25/wasi-sdk-25.0-x86_64-linux.tar.gz",
)
```

`BUILD.bazel`:

```starlark
# ...

cc_tool_map(
name = "wasm-cc-tool-map",
tools = {
"@rules_cc//cc/toolchains/actions:assembly_actions": ":clang",
# ...
}
)

cc_tool(
name = "clang",
src = "@wasi-sdk-x86_64-linux//:clang",
allowlist_include_directories = ["@wasi-sdk-x86_64-linux//:include"],
data = ["@wasi-sdk-x86_64-linux//:include"],
)

# ...
```

This would all be fine, except in [`getPermittedSystemIncludePrefixes`](https://github.com/bazelbuild/bazel/blob/8.1.1/src/main/java/com/google/devtools/build/lib/rules/cpp/CppCompileAction.java#L1685), Bazel ignores any system include prefixes that are not absolute. But Bazel also does not seem to provide any way to express my `@wasi-sdk-x86_64-linux//:include` directory with an absolute path. So there doesn't seem to be any way to use the unpacked system headers from the HTTP archive in my CC toolchain.

Is there some workaround I'm not seeing?

### Which category does this issue belong to?

C++ Rules

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

It seems like the only way to allow-list system header directories using `cc_tool` is to hardcode absolute paths like `/usr/include`. But this does not work when the paths are generated by some other build rule.

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

Linux

### 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` ?

I'm assuming this is referring to my repository, rather than the Bazel repository?

```text
git@github.com:vimana-cloud/rules_wasm.git
8fd6c5114e84d770640eca003fb3bfb6b3e417fb
```

You can reproduce the problem with:

```bash
cd example
bazel build '//c:foo-wrapper(core)'
```

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

People seem to be convinced that there is no way to turn a path relative to the exec root into an absolute path in Bazel.

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

_No response_

Start by reproducing the report with `cd example; bazel build '//c:foo-wrapper(core)'` from the linked `rules_wasm` revision. Then read `src/main/java/com/google/devtools/build/lib/rules/cpp/CppCompileAction.java`, especially `getPermittedSystemIncludePrefixes`; done means generated include directories from the shown `cc_tool` setup are accepted without hardcoded absolute paths.

Written by the indexing model from the issue text.