Move commerce to submodule

The tests should still be part of the root module, even though submodules. We can keep submodule specific tags.

I think it makes more sense to lump tests for commerce or ubercart, etc in the sub-module instead of the root commerce_migrate module.

One thing I just noted though... and this is different than how most other modules are doing things is that the destinations seem to be part of this module ecosystem. Rather than the commerce core modules themselves. I'd rather see them added to commerce core. This aligns with how drupal core does things. Honestly, I almost want to see that too for source and process too, but those are more d2d specific, so let's leave them in here. But destinations make more sense (to me) because technically you don't really *need* the process plugins or source plugins to import into commerce if you sucking in properly formatted data from a CSV. You just need all the correct destinations.

+++ b/modules/commerce/tests/src/Kernel/Migrate/d7/ProfileBillingTest.php
similarity index 91%
rename from src/Plugin/migrate/destination/commerce/d7/Profile.php

rename from src/Plugin/migrate/destination/commerce/d7/Profile.php
rename to src/Plugin/migrate/destination/Profile.php

rename to src/Plugin/migrate/destination/Profile.php
index b809b10..77a75b4 100644

index b809b10..77a75b4 100644
--- a/src/Plugin/migrate/destination/commerce/d7/Profile.php

--- a/src/Plugin/migrate/destination/commerce/d7/Profile.php
+++ b/src/Plugin/migrate/destination/Profile.php

This is what I'm talking about.

+++ b/modules/commerce/commerce_migrate_commerce.info.yml
similarity index 100%
rename from migration_templates/d7_billing_profile.yml

rename from migration_templates/d7_billing_profile.yml
rename to modules/commerce/migration_templates/d7_billing_profile.yml

Me likes this. Adding them to the 'commerce' module, without cluttering up the commerce module itself. However, shouldn't these go into the specific sub_module of commerce. Like order, product, etc? And does this work in a sub-folder or does the migration_templates folder need to reside in the root of a module? I think it does, based on what I'm seeing in MigrationPluginManager. It looks for migration_templates in the root of enabled modules. So much for wanting to break things out. Any chance we can put the process plugins and destination plugins directly into commerce core? Seems like that would get messy. The question of "where does this belong" would be troublesome.

So, after thinking about this some more... I propose we put all the commerce core destinations into commerce_migrate. You'll need them for any and all commerce migrations. Any process plugins that are specific to a uc, commerce 7, woocommerce, etc. migration move into their respective modules. However, if there are any generally useful (globally useful) process plugins, move those up into the root commerce_migrate parent module. The goal here being that if someone wants to write a custom migration of content from a CSV/excel file, they would just need to enable commerce_migrate to get the destinations and reusable process plugins.

One note about the process plugins, I don't expect there will be many generally useful process plugins. Except for ones that are similar between uc and commerce. In that case, let's add a base abstract process plugin into commerce_migrate and extend them into the sub modules. That will keep things cleanest. Even if we have to *only* extend the process plugin base and add annotations, we can then namespace it appropriately. Naming is hard, let's make it easiest on ourselves. And with how we are building things, we're going to have a hard time figuring out what is generally/globally useful until after the fact. So to maintain BC, we're going to want to build these things in commerce or uc first, then after a while we'll see that there are similarities and we can refactor them back to a common abstract base class.

Enough random ponderings. Is this clear now? Is there general consensus?

Oh, and this is obvious, but all source plugins for uc, commerce 7 etc should reside in the submodules. But if there are any similarities between uc and commerce 7, add base abstract classes in the core commerce_migrate module and extend them into the sub modules.

Looks good now.