This is a necessary preparation for moving the C# dependency management to `paket`,
which in turn is a necessary preparation for moving the C# build to bazel.
As we discovered in https://github.com/github/codeql/pull/16376,
`paket` tries to restore all projects recursively from the root folder.
If we support building C# code under both `ql/csharp` and `ql/cpp`, we need
to have a single lockfile under `ql`, as both codebases share the same set of dependencies
(and utilities from `ql/csharp/extractor`).
Then, `paket` will also try to restore things that look like "C# projects" in other languages'
folders, which is not what we want.
Therefore, we address this by moving all C# code into a common root directory, `ql/csharp`.
This needs an internal PR to adjust the buildsystem to look for the autobuilder in the new location.
This introduces tooling and enforcement for formatting bazel files.
The tooling is provided as a bazel run target from
[keith/buildifier-prebuilt](https://github.com/keith/buildifier-prebuilt).
This is used in a [`pre-commit`](https://pre-commit.com/) hook for those
having that installed. In turn this is used in a CI check. Relying on a
`pre-commit` action gives us easy checking that buildifying did not
change anything in the files and printing the diff, without having to
hand-roll the check ourselves.
This enforcement will make usage of gazelle easier, as gazelle itself
might reformat files, even outside of `go`. Having them properly
formatted will allow gazelle to leave them unchanged, without needing
to configure awkward exclude directives.
This is to check that the build from `codeql` works. The "official"
build will still be checked from the internal repo with QLucie, once
we integrate the bazel build there.
This PR introduces a bazel and `rules_rust`-based build system
for the ruby extractor and language pack.
This replacese the existing, `cargo` and `cross`-based build system.
For local development, nothing changes, and the existing `cargo`-based
build still keeps working as-is.
We no longer need to use `cross` to compile our Linux binaries,
as we now can link against our hermetic C++ toolchain, which ships
with an old enough glibc, so that we don't run into symbol version issues
when deploying the binaries to older systems.
Besides the one change in dependency (explained in detail in `Cargo.toml`
and in https://github.com/github/codeql/pull/15595), nothing ought to
change in how we build the extractor.
