Removing support for not supporting attribute-based discovery

Problem/Motivation

The plugin attribute/annotation deprecation currently has two separate, staged deprecations.

The current plan is/was to remove support for plugin managers that do not provide an Attribute class (in most cases, additionally to an existing annotation class for BC).

And the second stage is to remove support for not using the attribute class in a plugin, that's scheduled for removal in D13.

The reason for this is that contrib projects providing plugins for a plugin type provided by another contrib module (for example a webform handler) first need that contrib module to add support for attributes.

By forcing the plugin-type-providing contrib modules to add compatibility now, we ease the upgrade path/complexity for D13. there are a lot of modules providing plugin types, https://search.tresbien.tech/search?q=%22extends%20DefaultPluginManager%... has 1700 results.

The problem is that tooling (upgrade_status, phpstan, rector) do not yet support identifying or converting this, so it's missing visibility, will not be part of automated patches and so on (assuming it is not implemented until then).

We *could* postpone this to ease updating to D12, but we'll likely pay the price for that later.

Either way, BC support will work for contrib like it does for core, other modules can define both the attribute and the annotation. It would even possible to define an attribute class based on an assumption or not-yet-committed merge requests, but there's a risk that properties would not exist or have different names or something like that.

Steps to reproduce

Proposed resolution

Remaining tasks

Decide about removing the deprecated code path now or postpone it to D13.

I guess it still makes sense to do it, but wanted to make sure we make a deliberate decision on this.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet