Use PHP attributes instead of doctrine annotations for plugin type definitions

Lets also do core plugin type conversions for fields, constraints and views, those should all be supported since 10.3, we can raise that from 10.2 that we already require anyway.

+1 on #4 would be great if someone could improve the MR accordingly.
@primsi maybe?

thanks @primsi for the groundwork (our own plugin types were already fully on attributes, with the managers wired for attribute + annotation BC).

Completed the core plugin type conversions @berdir asked for in #4 (all supported since 10.3, so raised the floor to ^10.3 || ^11):

• @FieldWidget => #[FieldWidget] — EntityReferenceBrowserWidget, FileBrowserWidget (dropped the redundant explicit provider, it's auto-derived);
• @Constraint => removed the leftover annotation (the attribute was already there);
• @ViewsField => #[ViewsField] — SelectForm, SearchApiSelectForm;
• @ViewsFilter => #[ViewsFilter] — ContextualBundle;
• @ViewsArgumentDefault => #[ViewsArgumentDefault] — EntityBrowserWidgetContext;
• @ViewsDisplay => the views display plugin (see below).

The views display was the only non-mechanical one: it carries a custom entity_browser_display = TRUE property (used by Views::getApplicableViews() to find our displays), and the core #[ViewsDisplay] attribute has a fixed parameter list. So I added a small #[EntityBrowserViewsDisplay] attribute subclass that adds that one parameter and forwards the rest to core — same pattern core itself uses for its entity_reference_display marker. Discovery picks the subclass up because core matches with ReflectionAttribute::IS_INSTANCEOF, and AttributeBase::get() reflects the extra property into the definition.

Left out of scope on purpose: the @FormElement Element plugins are being converted in #3613186 (coupled to the FormElementBase / ^10.3 change there — doing them here too would just conflict), and the @ConfigEntityType on the entity is an entity type rather than a plugin.

Environment

• Drupal: 11.4.4
• PHP: 8.5.5
• Database: MariaDB 10.11.16
• DDEV: v1.25.2
• Entity Browser: 8.x-2.x-dev (MR !78, da1f50c)
• Browser: Chrome

Prerequisites

• Enable the module, its example module and Media (the media_image_upload widget is only discovered when Media is installed):
  

  ddev drush en entity_browser entity_browser_example media -y

• The example module provides four entity browsers (test_files, test_files1, test_files_ajax, test_nodes) covering the iFrame and Modal displays, and the entity_browser_test content type whose form uses five Entity Browser field widgets.
• Baseline reference for comparison is the unmodified 8.x-2.x branch.

Steps

1. Apply the fix from MR !78: all plugin classes are converted from Doctrine annotations to PHP attributes, new attribute classes are added under src/Attribute/, the six plugin managers are switched to attribute discovery, the core plugin types (FieldWidget, Constraint, Views field/filter/argument default/display) are converted as well, and the core requirement is raised to ^10.3 || ^11.
2. Rebuild caches: ddev drush cr
3. Go to /node/add/entity_browser_test and confirm that all five Entity Browser widgets render: Files (iFrame display), Files 1 (Modal display), Files over AJAX (iFrame), Image browser (file browser) and Nodes (iFrame).
4. Open each browser with its Select entities button and confirm the iFrame opens inline, the Modal opens in a dialog, the widget selector tabs are visible, and a selected entity is returned to the field with its label or thumbnail.
5. Go to /admin/config/content/entity_browser and confirm every browser can be edited, with all display, widget selector, widget and selection display plugins listed in their select lists.
6. Compare the full plugin definition set against the baseline branch for the six Entity Browser plugin types plus the Views display, Views field, Views filter, Views argument default, FieldWidget and Constraint plugins.
7. Run the kernel tests:
   

   ddev exec 'cd /var/www/html/web && ../vendor/bin/phpunit -c core/phpunit.xml.dist modules/contrib/entity_browser/tests/src/Kernel'

Expected results

• No annotations remain in the plugin classes; all plugins are discovered from attributes.
• The plugin definition set is unchanged: same plugin IDs, classes, labels, descriptions and custom keys (auto_select, entity_browser_display, entity_reference_display) as on the baseline branch.
• All five field widgets render and function identically to the baseline; entity selection through the iFrame and Modal displays still returns the selected entities.
• Entity browser configuration forms keep listing every plugin.
• Kernel tests pass.

Actual results

The conversion works. All 26 plugin classes are on attributes with no annotation left, and every plugin type keeps its complete definition set: the three displays, three widgets (including media_image_upload), three selection displays, three widget selectors, three widget validators, three field widget displays, the two field widgets, the Views display, field, filter and argument default plugins and the image dimensions constraint are all discovered, with the custom definition keys preserved. In the browser both before and after the change all five widgets on /node/add/entity_browser_test render, the iFrame and Modal displays open, the widget selector tabs work and selected entities are returned to the field; the configuration forms are unaffected. Kernel tests pass (9 tests, 77 assertions); the reported deprecations come from Symfony and PHPUnit, not from the module. One regression was found and fixed on the MR branch: in src/Plugin/EntityBrowser/FieldWidgetDisplay/RenderedEntity.php the attribute description had been copy-pasted from ImageThumbnail and read Displays image files as thumbnails instead of the original Displays fully rendered entity.. It is not shown in the UI, since the field widget settings form only renders plugin labels, but the plugin definition was factually wrong, so it was restored in commit da1f50c ("Issue #3522955: Restore the RenderedEntity plugin description"). After that commit the plugin definition set matches the baseline branch exactly.

Unrelated to this issue: on the pages containing an entity browser view, the admin theme logs a Using null as an array offset deprecation from views-view-field--status.html.twig (Gin and core's default_admin), because row.node_field_data_langcode is empty in that view. This is present on the unmodified 8.x-2.x branch as well.

Testing produced with the assistance of an LLM.

did a bit of cleanup on the attribute classes, found one unconverted plugin in the entity form submodule.

Also converted the entity type, the deriver is a a bit tricky on that extend views plugin, but we can just not call the parent. But I think we don't need that all. It's not nice, but we can use an alter hook to add that in, there is no other plugin in contrib that does that, it's a lot of code just to avoid the alter hook.

Merged.

Thanks @berdir for the lot of work