Add self-checks for the configuration. They fail if hook doesn't apply
to any files in the repository, or if the excludes contain extraneous
files that wouldn't be included anyway. It is helpful for detecting
simple mistakes. For this reason, remove the symlink target check since
we have no symlinks in the repository.

There's no desire to update the uv.lock in source code control when
executing these commands: it can only trigger noise and confusion.

This can happen if you have some custom uv config on your machine which
would resolve packages differently (e.g. UV_DEFAULT_REGISTRY=)

This delivers a clear error message if the user happens to have
a too-old prek, rather than something confusing.

We require the 0.2.29 which supports includes/excludes as yaml glob
lists rather than the previous regexp approach, this is just a massive
improvement to the maintainers of these files:

https://github.com/j178/prek/releases/tag/v0.2.29

Improves the output from the github workflow if something had to be
reformatted or fixed.

Integrates prek as a repository scanner and pre-commit tool. It has some built-in 
rust checks that run across the repository, and can also integrate external tools.

External tools are managed as pypi dependencies with uv, just explicitly instead 
of using prek's built-in uv support. You need uv either way.

shellcheck, actionlint, zizmor, ruff, rumdl, and ast-grep tools are initially integrated.
We can migrate other checks from the gradle build here with follow-up commits.

The CI is reorganized to run this "quick check" before any of the heavy java jobs. 
Current job in the worst case (cache miss) runs in less than a minute: so it does 
not slow down feedback to the user, but saves a lot of CI minutes. good task for 
ubuntu slim runner.

To try the functionality out locally:

You need uv package manager: https://docs.astral.sh/uv/getting-started/installation/
You can then change some code and try out a precommit-run with `uvx prek`
To do this automatically as git-hook, use `uvx prek install`.

Locally, the checks are fast, since generally only the files you touched are being
passed to the checker. So the pre-commit git hook is actually not annoying (< 1s).

The checker is configured with some autofix support. All of the current "Check" 
steps run in parallel, then the "Fix" steps run sequentially in the order they are 
defined in the `.pre-commit-config.yml` file. 

`Fix` solution is always preferred to make it easier on the user, the individual
steps will use multiple cores anyway.

Fixes will still "fail" the `git commit`, but they'll make the changes for you locally. 
You just need to review and `git add` the fixes made, then `git commit` again.

Closes apache#15626