Show migrate plugins on the Migrate UI lists

I think the problem is like this:

• With core migrate, we get a lot of migration plugins that we never want to execute, and which we only want to use as templates.
• With migrate_plus migration config entities, we get into a scenario where the only migrations we do want to run are those that are based on config entities. This is why in general it is fine that the other migrations don't show up in the UI.

So, the config entities do solve the problem of distinguishing migrations we want to execute, vs migrations we only see as templates.
And they provide a way to edit the "real" migrations as yml files.

However, in general the config entities are something we did not ask for.
A lot of the functionality that is currently based on these config entities, such as groups and the UI, could have been done on the regular plugins instead.
We would just need a different way to distinguish the "actual" migrations from the "template" migrations.

So, for this issue, if we make all migration plugins available in the UI, we need to provide some tools to mark migration plugins as "template" or "actual", and to make this distinction visible in the UI.

With core migrate, we get a lot of migration plugins that we never want to execute, and which we only want to use as templates.

I just want to note, these aren't meant to be templates, these are actual migrations, intended to be run to upgrade a site, and the yml plugins provided by all of core and contrib are built with the intention that they be run. Many people use them as templates to build their own migration plugins or configs, but we can't just assume that they are to be treated only as templates.

these aren't meant to be templates, these are actual migrations,

True,
Still, these contain a lot of migrations that are not applicable to the particular project.
E.g. you get `d6_user`, even when all you want is upgrade from a Drupal 7 database.

If you rely on these out of the box migrations, you need to be very selective which migrations to run and which not to run.
Once you switch over to migrate_plus, with the config entities, you typically want to ignore the non-config migrations.
Otherwise you get duplicates on import.

And if you used the out of the box migrations before, and want to transition over to migration config entities, you need to properly roll back the old migrations, or somehow rename the migrate_map_* tables (which I did).

I stumbled upon this issue when debugging not working migration plugins generated with drush gen migration. It turned out the generator was creating the plugin in the migration directory as opposed to migrations (singular vs plural).

I see many references on the internet referring to `migration` directory, and this issue is one of them. That creates some confusion so I had to debug the code to find out which directory exactly is to be used.