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 initial change is a bit of a hacky way to achieve our goals (since
it doesn't rewrite all the uses of this.strict), but it is easy to
understand is correct. Let's accept test changes NOW, and ensure that
later changes don't change things further.
Created shared AbstractDetector to not duplicate all the tedious logic
;)
I took inspiration from the tests in `javascript/extractor/tests/esnext/input/dynamic-import.js`
On Windows, the project layout needs to match `codeql~override`, while
on POSIX we must keep on matching `ql`. We work around this by using
`*ql*` in the project layout, which matches both.
Previously, we had a `sh_test` wrapping the `java_test` to do some setup.
This was extremely brittle on Windows, and relied on getting a deploy
jar from `java_test`. This breaks when updating to Bazel 7, where the
ability to get a deploy jar from `java_test` was removed.
Therefore, we now do all the test setup in `AllTests.java` instead.
This is much cleaner, and shouldn't break as easily.
`this` didn't refer to anything specific, and it was in fact `undefined` in the context it was invoked. There was already a `let typeTable = this;` further up (where `this` refers to the class instance), so I used `typeTable`.
