Fix Drupal 12 deprecations: migrate hooks to OOP classes and fix views_data_alter fatal

Hi @berdir, thanks a lot for the pointers on #3576977 — this got the ball rolling nicely.
Pushed the first pass (MR !150), here's a friendly summary of where things stand.

What this MR does

Starting from bbrala's bot rector patch, plus mirroring what we did in dropzonejs #3576977:

- Procedural hooks => OOP #[Hook] classes (EntityBrowserHooks, EntityBrowserViewsHooks, and the entity_form submodule) with #[LegacyHook] wrappers and services.yml autowire. This moves hook_views_data_alter() into EntityBrowserViewsHooks::viewsDataAlter() and clears the entity_browser_views_data_alter fatal.

- Split the hooks with proper DI, so there are no \Drupal:: calls left in the new hook classes (phpstan-friendly), just like you suggested for dropzonejs.

- Three extra install-blocking D12 fatals the bot patch didn't cover, caught by running the suite against real 12.0-dev:
1. EntityBrowserFormController::getFormObject() used $this->request->get() (Request::get() is gone in Symfony 7) => ->query->get('original_path').

2. EntityBrowserListBuilder::getDefaultOperations() — D12 added a second CacheableMetadata $cacheability argument. Made the override compatible across 10.2–12 (?CacheableMetadata $cacheability = NULL + null-safe cacheability), and added a small regression kernel test (EntityBrowserListBuilderTest) so this can't sneak back.

- core_version_requirement => ^10.2 || ^11 || ^12, .gitlab-ci.yml next-minor/next-major + _LENIENT_ALLOW_LIST, and #[Group] / #[RunTestsInSeparateProcesses] for PHPUnit 12.

CI picture (and the good news)

- Current core (11.4.4): 53/57 green. The 4 red ones are all entity_embed + CKEditor5 (CardinalityTest::testEntityEmbed and the three EntityEmbedTest cases), failing inside core's CKEditor5TestTrait. These are not from this MR — the base 8.x-2.x pipeline on the same commit (54253b3, pipeline #896776) fails the exact same four, and they're already being handled in #3612718. The new EntityBrowserListBuilderTest passes on both 11.4 and 12.0-dev.

- Next major (D12): the remaining failures are all Class "Drupal\Core\Render\Element\FormElement" not found — FormElement was removed in D12 and EntityBrowserElement / EntityBrowserPagerElement still extend it. That's the one big blocker left, and it's already tracked in #3565236 (fix is FormElement => FormElementBase, which needs 10.3).

============================================

Would you rather I fold the FormElement => FormElementBase change into this MR (bumping to ^10.3 and dropping 10.2, as we did in dropzonejs) so next-major goes much greener — or keep that in #3565236 and keep this MR focused on the hook/OOP + fatal fixes? Happy either way, just don't want to step on that issue's scope.

The remaining phpcs/phpstan/eslint/cspell/stylelint reports are the module's existing baseline (the new hook classes are clean); those look like they belong in #3541968 rather than here.

Thanks again!

Thanks @berdir, all addressed and pushed.

A couple of things worth calling out beyond the diff:
- trustData() — since it's deprecated in 11.4 anyway, I just dropped it rather than swapping the call, per your hint.

- views.inc — I moved the leftover #[LegacyHook] wrapper into .module and deleted the .inc (it was still tripping the "autoloading hooks in .inc is removed in D12" deprecation). Shout if you'd rather keep that for the follow-up.

- Folded in FormElementBase + ^10.3 as discussed — credits merge sounds good.

On CI: the current-core reds are just the entity_embed/CKEditor5 ones from #3612718 (same on plain 8.x-2.x). Next-major is green for everything this MR touches; what's left there is those CKEditor tests, a few not-yet-D12 cross-deps from the lenient list, and modal.js choking on jQuery 4 — that last one's a separate D12 JS follow-up, no JS changed here.

Sounds like a good plan, and agreed on not flagging D12 compatible until the JS and plugin-attribute pieces are sorted — the uncertainty around core enforcing attribute classes is a good reason to hold.

Set up the tree as you suggested:
- Parent: #3613379: Drupal 12 compatibility
- This issue (#3613186) — moved under it as a child. I removed the || ^12 from entity_browser.info.yml (kept ^10.3 for FormElementBase), so it's now purely the D12 preparation step — OOP hooks, the install-blocking fatals, FormElementBase — without claiming compatibility. Still enough to unblock dropzonejs/paragraphs testing via the lenient list. Rebased on the merged test fixes so the phpunit job is green.
- JS follow-up: #3613381: Fix jQuery 4 (Drupal 12) deprecations in JavaScript — child of the parent, MR up. It's a mechanical sweep, verified to be a no-op on the current jQuery 3.x, so no behaviour change on 11.x; the next-major CI job is where it earns its keep (that's where modal.js was throwing under jQuery 4).

For the plugins piece: turns out there's already #3522955: Use PHP attributes instead of doctrine annotations for plugin type definitions — and you'd already expanded its scope in #10 there to also cover the core field/constraint/views plugin conversions. Rather than open a duplicate I've linked it as the third child of #3613379. Shout if you'd rather have a fresh one scoped specifically to "attribute classes for every plugin manager".