extend "includes = " to generate a src include path, or bazel-out include path, but not both

### Description of the bug:

In our large codebase, we use includes = [] to declare an include path for all dependees of a cc_-target. We either:

1) Declare an include path for headers in the workspace tree:

```
cc_library(
hdrs = glob("*.hxx"),
includes = ["."],
)
results in compiler args:
- /Ipath/to/lib
- /Ibazel-out/x64-windows-opt/path/to/lib
```

2) Declare an include path for generated headers found in the bazel-out tree:

```
my_codegen(
name = codegen,
out = "gen",
)
cc_library(
srcs = [":codegen"]
hdrs = [":codegen"]
includes = ["gen"]
)
results in compiler args:
- /Ipath/to/lib/gen
- /Ibazel-out/x64-windows-opt/path/to/lib/gen
```

We never (almost never) require a directory to be on the include path for both workspace tree and bazel-out tree.

However, when we generate compile_commands.json files, we note that the include paths being passed to the compiler contains paths both for bazel-out, and workspace, for all entries in includes. Parameters for a single compilation action total 25kb, and around 60% of this is unnecessary /I options.

This ask is for some way to control whether entries in includes apply to workspace tree, bazel-out tree, or both. It could be some prefix in the include path, or some extra keywords (workspace-includes = [x], gen-includes = [y]), or something else.

Benefits would be:
* Surely would improve performance
* Compile_commands.json would be much smaller (300MB vs 750MB for us).

### 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.

_No response_

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

windows

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

7.3.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` ?

_No response_

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

Lots of people complain about the size of compile commands. One reported file is 10GB, in a bazel scenario.

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

_No response_

Start by tracing how C++ rules turn includes into compiler arguments and how compile_commands.json is generated on Windows. Compare workspace and bazel-out paths in a minimal cc_library and codegen setup. Done means callers can select workspace, bazel-out, or both for include entries, with reduced duplicate /I options and corresponding coverage.

Written by the indexing model from the issue text.