Enable candidate `DynamicPropSource` suggestions for code components: refactor `GeneratedFieldExplicitInputUxComponentSourceBase` and `FieldForComponentSuggester` to need only SDC's ComponentMetadata, not SDC plugin instances

Overview

#3498889: ComponentSource plugin for code components introduced GeneratedFieldExplicitInputUxComponentSourceBase. In order to make most of the logic in that class (which powers the input UX for the "SDC" and "JS aka code component" ComponentSource plugins) work, it needs an SDC plugin instance.

Changing it to not need that would've led to even more refactoring in #3498889 than it already did.

Additionally we're hard-coding Article nodes in the same file

// 💻️ app/modules/experience_builder/src/Plugin/ExperienceBuilder/ComponentSource/GeneratedFieldExplicitInputUxComponentSourceBase.php:447
$suggestions = $this instanceof SingleDirectoryComponent
      ? $this->fieldForComponentSuggester->suggest($component_plugin->getPluginId(), EntityDataDefinition::create('node', 'article')) // 👈️👈️👈️👈️ 
      : [];

Proposed resolution

• Refactor all the XB-owned infrastructure to not expect an SDC plugin instance as an argument, but only a subset of that plugin instance: a ComponentMetadata object.
• Start with GeneratedFieldExplicitInputUxComponentSourceBase
• Note: this may require in some places an ephemeral SDC plugin object (not tied to an actually installed SDC on disk) to be generated from that metadata object, for example to be able to call SDC's \Drupal\Core\Theme\Component\ComponentValidator::validateProps().
• Then move on to \Drupal\experience_builder\ShapeMatcher\FieldForComponentSuggester.
• Expected end result: SingleDirectoryComponent or JsComponent-specific checks/logic remain.

This will allow docs/components.md to be updated to state something like:

Any `Component Source Plugin` without a native (explicit) input UX can reuse the infrastructure that XB originally
built to provide an input UX for `SDC`-sourced `Component`s. To generate an input UX,  the precise shape of each
input (and it being required or optional) must be expressed in a standardized way. To avoid inventing new infrastructure,
XB opted to rely on the SDC subsystem of Drupal core's abstraction for expressing this: the `ComponentMetadata` class.

While imperfect (because it contains _all_ metadata rather than only that relating to its explicit input shapes), it is
the pragmatic choice to get the job done. See [`XB Shape Matching
into Field Types` doc](shape-matching-into-field-types.md) for details on how that works.

In other words: _any_ `Component Source Plugin` can use the same Drupal Field-powered UX that XB provides for SDCs,
all it requires is generating a `ComponentMetadata` object that expresses its input schema.

@see \Drupal\Core\Theme\Component\ComponentMetadata

User interface changes

None.