Feeds Migrate MVP: Use external form classes for source, data_parser, data_fetcher and destination plugins

As part of the MVP (https://www.drupal.org/project/feeds_migrate/issues/3020397) we need to architect a plugin system to add configuration UX to existing migration plugins (i.e. source, data_parser, data_fetcher and destination). There already is some work done in the codebase for destination plugins. Using external form classes we can extend existing plugins and expose them to the UX. See /src/Plugin/ExternalPluginFormBase.php for an example). With the hook hook_migrate_xxx_info_alter(), we can alter the definitions of existing migration plugins and add a definition for referencing a form class in there.

We would then for example get the following class:

namespace Drupal\feeds_migrate\Plugin\migrate\data_fetcher\Form;

/**
 * The configuration form for the migrate file data_fetcher plugin.
 */
class FileForm extends ExternalPluginFormBase {

  /**
   * {@inheritdoc}
   */
  public function buildConfigurationForm(array $form, FormStateInterface $form_state) {
    // @todo implement.
  }

  /**
   * {@inheritdoc}
   */
  public function buildImporterForm(array $form, FormStateInterface $form_state) {
    // @todo implement.
  }

}

where the base class looks something like this:

namespace Drupal\feeds_migrate\Plugin\migrate\data_fetcher\Form;

/**
 * Base class for Migrate plugins that have external configuration forms.
 */
abstract class ExternalPluginFormBase implements PluginFormInterface, PluginAwareInterface {

  /**
   * The Migrate data_fetcher plugin.
   *
   * @var \Drupal\migrate_plus\DataFetcherPluginInterface
   */
  protected $plugin;

  /**
   * Sets the Migrate plugin.
   *
   * @param \Drupal\migrate_plus\DataFetcherPluginInterface $plugin
   *   The Migrate plugin.
   */
  public function setPlugin(DataFetcherPluginInterface $plugin) {
    $this->plugin = $plugin;
  }

  /**
   * {@inheritdoc}
   */
  public function buildConfigurationForm(array &$form, FormStateInterface $form_state) {
    // @todo build the form
  }

  /**
   * {@inheritdoc}
   */
  public function validateConfigurationForm(array &$form, FormStateInterface $form_state) {
    // Validation is optional.
  }

  /**
   * {@inheritdoc}
   */
  public function submitConfigurationForm(array &$form, FormStateInterface $form_state) {
    // @todo save the configuration on the migration entity.
  }

  /**
   * {@inheritdoc}
   */
  public function buildImporterForm(array &$form, FormStateInterface $form_state) {
    // @todo build the form
  }

  /**
   * {@inheritdoc}
   */
  public function validateImporterForm(array &$form, FormStateInterface $form_state) {
    // Validation is optional.
  }

  /**
   * {@inheritdoc}
   */
  public function submitImporterForm(array &$form, FormStateInterface $form_state) {
    // @todo save the configuration on the migration entity.
  }

}

Contributed modules that are providing plugins and that would want to support our UI, just have to define an additional key in their annotation:

/**
 * @DataFetcher(
 *   id = "foo",
 *   title = @Translation("Foo")
 *   form = "Drupal\foo\Plugin\migrate_plus\data_fetcher\Form\FooForm",
 * )
 */

Plugins in core don't have to do this: we would use the hook hook_migrate_xxx_info_alter() to add these in for them.

This idea is taken from the Feeds module where fetchers, parsers and processors all declare external form classes. Also see #2991199: Use external form classes for configuring process plugins and #3002362: Foundation: Feeds migrate Processors/Tamper UI , where this idea is proposed for process plugins as well (i.e. feeds tampers)