Automated Drupal 12 compatibility fixes for admin_toolbar 3.x-dev

This is going to go in the 4.x branch to be created soon, which will support drupal core 11.5+ and 12.

See: #3565206-8: [Meta] Roadplan for Admin Toolbar 3.6.x and 4.x

We will come back to this issue later, when the 4.x branch is created and we start the D12 compatibility work.

We tested the automated changes from run 12-884047 (comment #8) on a
multi-tenant Drupal 11.4.5 site and they work. Applied on top of 3.x:

- The site bootstraps and rebuilds caches without errors.
- hook_toolbar still returns the Admin Toolbar items, and the four new
hook classes resolve correctly as autowired services.
- No functional regressions found in Admin Toolbar or Admin Toolbar Extra
Tools (the two submodules we run).

Two things the bot's output needs before it can be committed, both fixed in
the merge request linked above (comments only, no functional change):

1. In admin_toolbar_links_access_filter.install, an empty "@file" doc block is
inserted above the existing one, producing a duplicate and a PHPCS error
("Missing short description in doc comment"). This looks like a Drupal
Rector problem rather than something specific to this module, so it will
probably reappear on the next run.
2. The comments moved into the new hook classes keep their original
indentation, so they end up misaligned inside the method bodies (most
visibly in AdminToolbarSearchHooks::toolbar(), where comments inside the
render arrays are indented by 14 spaces) and 23 of them exceed the
80-character limit.

With those two fixed, "phpcs --standard=Drupal" is clean on the whole module.

Two further notes:

- The merge request applies to 3.x, but not to the 3.6.3 release: four hunks
conflict and two test files it touches do not exist in the tag. Anyone
patching a pinned stable release will need to rebase it.
- The PHPStan job goes red: the module's own phpstan.neon (level 6) reports 29
errors on the bot's branch. Two causes, both a direct consequence of moving
the hooks into classes:

1. The three ignoreErrors entries match "Function admin_toolbar_*()" in
*.install and *.module. The hooks are now methods in .php files, so the
suppressions no longer apply and the "no return type specified" /
"no parameter type specified" errors surface again. Those are the errors
the config comment says are deliberately ignored for hook implementations.
2. "\Drupal calls should be avoided in classes" now fires 15 times. The rule
could not fire while the code lived in procedural functions.

Neither is caused by the coding-standards commit in this merge request: the
error count is identical with and without it (we checked both commits).
Fixing it is a maintainer decision, so we did not touch it here. Either the
ignoreErrors patterns get extended to the new hook classes, or the services
get injected into their constructors properly. We are happy to do the
dependency injection work for 4.x if that is the direction you want.

- PHPStan also flags
AdminToolbarToolsHooks::formProjectBrowserSettingsAlter(&$form) as an invalid
form-alter signature (expected &$form, FormStateInterface $form_state[,
$form_id]). Pre-existing in the procedural version and harmless at runtime,
but it only becomes visible once the hook is a class method.

@dydave: understood from #7 that this is going to 4.x. We have also prepared
the info.yml side of that (dependency on toolbar:toolbar and ^12 in
core_version_requirement) for our own use, and we are happy to contribute it
once the 4.x branch exists. Just let us know.

We will come back to this issue once the Toolbar module has a D12 compatible release.... very soon....

The D12 version of admin toolbar will sit in the 4.x branch and support ^11.5 || ^12, like the contrib toolbar module 2.x.