Read component definitions from our own service, not from plugin.manager.sdc

Problem/Motivation

We decorate plugin.manager.sdc and our code asks that service for our annotated definitions. That holds only while we are the outermost layer. Canvas replaces the class of the service and aliases its class to it: with both modules installed, its alias resolves to our manager and every Canvas call typed against its class throws a TypeError, recipes included (#3623504: Recipe apply fails with a TypeError when Canvas is installed). A module decorating outside of us (Pinto, #3619953: Update service injections to use lowermost class, permitting further downstream extensions of SDC) gets a fatal on our methods. A decorator inside of us is ignored, because our manager runs its own discovery instead of reading the decorated service.

Our annotations in the shared definitions also break Canvas functionally: with them, Canvas keeps 5 of its 47 test components.

Proposed resolution

Our code gets its definitions from Drupal\ui_patterns\ComponentPluginManager, by its own service id, whatever plugin.manager.sdc is. The manager becomes a plain decorator: it annotates decorated->getDefinitions() and runs no discovery of its own. Annotation moves to a stateless ComponentDefinitionAnnotator, reused by a decorator of core's ComponentValidator so that props typed only by $ref: ui-patterns://… still validate.

The decoration of plugin.manager.sdc stays for third-party code reading our annotations there, and is skipped when a module replaces the class of the service, as Canvas does. Removed in 2.1.0.

Test modules decorating plugin.manager.sdc like a third party, inside and outside of us, synthesizing a raw component.

Remaining tasks

Separate issues, each a few lines:
- our plugin managers are not tagged plugin_manager_cache_clear (theme install fails when a prop type module comes with it);
- a required entry without a declared prop creates a typeless prop, rejected by core;
- json-schema 6.9+ names resolved schemas $id, we read id.

display_builder reads our annotations from plugin.manager.sdc and has to move to our service.

API changes

No signature changes. New service alias plugin.manager.ui_patterns_component. Decorating plugin.manager.sdc is deprecated, removed in 2.1.0.

Release notes snippet

UI Patterns now reads component definitions from its own service and no longer depends on being the outermost decorator of plugin.manager.sdc. Canvas, Pinto and other modules touching that service can be installed alongside, in any order. Code reading UI Patterns annotations from plugin.manager.sdc should use plugin.manager.ui_patterns_component instead; the decoration is deprecated and removed in 2.1.0.