Support alternate solution for bazel based C++ builds

Currently the [codeql documentation](https://docs.github.com/en/enterprise-cloud@latest/code-security/codeql-cli/getting-started-with-the-codeql-cli/preparing-your-code-for-codeql-analysis) contains this example for use with bazel based projects:

```
# Navigate to the Bazel workspace.

# Before building, remove cached objects
# and stop all running Bazel server processes.
bazel clean --expunge

# Build using the following Bazel flags, to help CodeQL detect the build:
# `--spawn_strategy=local`: build locally, instead of using a distributed build
# `--nouse_action_cache`: turn off build caching, which might prevent recompilation of source code
# `--noremote_accept_cached`, `--noremote_upload_local_results`: avoid using a remote cache
# `--disk_cache=`: avoid using a disk cache. Note that a disk cache is no longer considered a remote cache as of Bazel 6.
codeql database create new-database --language= \
--command='bazel build --spawn_strategy=local --nouse_action_cache --noremote_accept_cached --noremote_upload_local_results --disk_cache= //path/to/package:target'

# After building, stop all running Bazel server processes.
# This ensures future build commands start in a clean Bazel server process
# without CodeQL attached.
bazel shutdown
```

The gist of this is that you must start from scratch and build the whole project on the local machine without any caching. For many projects that moved to bazel moving away from this model was one of the core motivations. For large builds that rely on caching / remote execution, it may no longer be feasible to run the entire build on 1 machine, even if it's only on a scheduled cadence. Moreover the user might not even host the infrastructure to do this anymore, as all of their actual developer and CI builds go through remote execution.

It would be great if there was another way to communicate the necessary information to codeql, in a way that could work alongside bazel's model.

I can't tell from the documentation what the codeql CLI is actually pulling from the build, and I imagine it's quite in depth, but I assume there are other models that could work for providing the same information for certain types of builds.

For example for C++ some natural alternatives (from the user perspective) would be to:

- produce a compile_commands.json, which is also used in many other developer workflows like C++ LSPs
- produce a [clang indexstore](https://docs.google.com/document/d/1cH2sTpgSnJZCkZtJl1aY-rzy4uGPcrI-6RrUpdATO2Q/edit?tab=t.0#heading=h.rug5h2p4haqb), which can be used as a query-able database for the project
- produce a [kythe](https://github.com/kythe/kythe) index
- produce a [scip-clang](https://github.com/sourcegraph/scip-clang) index

Each of these options would work better in the bazel model, since indexes could be produced remotely, and cached, and compile_commands.json should already be supported for developer workflows.

related:

- https://github.com/github/codeql-cli-binaries/issues/9
- https://github.com/github/codeql-cli-binaries/issues/12

Commencez par la documentation CodeQL liée et le workflow Bazel existant, puis déterminez quelles informations de build la CLI requiert lors de la création de la base de données. Comparez les approches proposées avec compile_commands.json, clang indexstore, Kythe et scip-clang, notamment les contraintes liées à l’exécution distante et à la mise en cache. Le travail est terminé lorsqu’une alternative prise en charge est définie et que ses exigences en matière de documentation et de validation sont claires.

Rédigé par le modèle d'indexation à partir du texte de l'issue.