Provide a means of explicitly registering migrations

Problem/Motivation

Right now, it's difficult with the 8.1.x migration system to identify migrations that are "ready-to-use". For example, if you have custom migrations setup, and also happen to have migrate_drupal enabled but have not configured any Drupal migrations, you want drush migrate-status to list only your custom migrations. Unfortunately, excluding those unwanted Drupal migrations in a general way is... problematic. This is a major hurdle to development of general-purpose tools.

Proposed resolution

Introduce an explicit "registration" capability. Looking at what we've done in the past, two options are:

1. In D7, there was a registerMigration() API which would add a row to the migrate_status table representing the migration being registered - you could call it explicitly at runtime, or provide migration configuration in hook_migrate_api() which would be fed into the registration process. The tools then would manage only migrations found in that table - you might have migration classes in your environment (like migration plugins in 8.1.x), but they would be invisible to the tools until registered. A D8 version of this approach would, of course, use state rather than a table to record registrations.
2. In 8.0.x, runnable migrations were configuration entities and tools could identify them simply with an entity query. A module could either provide these entities directly in config/install, thus "registering" them at install time, or implement them as migration templates - these templates could then be configured with any additional configuration they needed (such as a database connection) and saved as configuration entities. So, in 8.1.x we could treat the raw migration plugins as templates providing default configuration, and save fully-configured migrations as configuration entities. The issue here will be executing the plugins with the overridden configuration - we'll need to address #2681869: Provide clean way to merge configuration into migration plugins.

I'm leaning towards the configuration entity approach - this is something we'll want anyway to support fully configuring migrations through a UI.

Remaining tasks

Start with a POC.

User interface changes

API changes

Data model changes