Make migrations themselves plugins instead of config entities

Problem/Motivation

As argued in #2462233: Migrations should not use the configuration entity system migrations should not use the config system. Now I agree they should not be config but instead should be plugins. Note the original issue did not suggest plugins, this was an idea of phenaproxima which I now consider doable based on a new, more complete understanding of the plugin system I've acquired during the long and hard debugging of #2605684: Routing silently fails in kernel tests.

Proposed resolution

Make them plugins. The current YML files themselves become a plugin each via a custom discovery. UI and code provided migrations still go into the config active store and retrieved as plugin derivatives.

Benefits of approach

• No more templates, custom to the Migrate API and hard for others to understand.
• No more builders, this now uses derivates like other parts of core. E.g. menu blocks.
• No more config objects but still a simplified YAML file to describe migrations.

Remaining tasks

1. Add back a query system. This will be done in a followup. The config entity query is easy to extend for this -- only the loadRecords method needs to be overridden.
2. Dependency/requirements handling is also a followup.

User interface changes

API changes

Migration entity is gone so Migration::create and Migration::load calls need to be converted. Migration::create($config) in tests becomes simply new Migration([], uniqid(), $config); and the use statement needs to change from Entity to Plugin. Migration::load($id) becomes \Drupal::service('plugin.manager.migration')->createInstance($id). Once you have a Migration object -- now a plugin -- the methods are the same. A followup will make it necessary to change the use statement for the MigrationInterface as it will also move from Entity into Plugin.

For code provided migrations here's an example from MigrateTaxonomyTermStubTest:
Before:

<?php
    $term_migration = Migration::create($config);
    $term_migration->save();
?>

<?php
    $term_migration = MigrationConfigDeriver::save('terms', $config);
?>

There is no create because, well, there's nothing save-able to create.

Data model changes