Add ability to configure allowlist for client_env

### Description of the feature request:

Currently, Bazel ingests all of the environment variables visible from its invocation context and sends them to actions executed during the build phase. These are also forwarded to BES.

It is not uncommon for environment variables to contain client secrets for various reasons; one common example is secrets for authenticating to services in a CI environment.

It would be great if Bazel had a pair of options like `--client_env_allowlist` and `--client_env_blocklist` which would allow selecting or deselecting the set of environment variables that should be consumed from the client's environment. Perhaps these options would allow passing a regular expression, such that one could do e.g. `--client_env_blocklist='.*(SECRET|KEY|TOKEN).*'`.

### Which category does this issue belong to?

Configurability

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

Exfiltrating the client environment to a remote server through BES, especially one with persistence, is a route for leaking secrets. It would be best to prevent this at the source, i.e. through a configuration option on bazel.

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

MacOS

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

release 6.3.2

### 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 master; git rev-parse HEAD` ?

_No response_

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

https://github.com/bazelbuild/bazel/issues/10996 seems related, but doesn't discuss the security issue

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

_No response_

Start by reviewing related issue #10996 and tracing how Bazel consumes client_env and forwards environment variables to BES. Clarify the interaction between the proposed allowlist and blocklist options, including regular-expression behavior. Done means the selected environment variables are consistently controlled before reaching build actions and BES, with documented behavior and coverage for the security concern.

Written by the indexing model from the issue text.