Move typed data extensions to final location

+1 to ctools module

While I was very fond of the ctools approach, I think it's just wrong. First off, it creates some maintenance burden and confusion as we cannot roll separate releases. But moreover, I think it does not establish the right culture of making code re-usable and and providing more, small re-usable packages for developers.

Those, small re-usable packages are of no interest for a regular user and do not need installation / uninstallation procedure is there is they may not have data or configuration attached. Therefore, having them as composer package makes a lot of sense.

However, those small re-usable packages often need to register services.

Providing plugins is a bit trouble-some. As soon as a plugin is used as part of some configuration, it would be relevant for the dependency system. But with a composer package, there is no provider the dependency system could rely upon. Moreover, often plugins are user-facing as users can select them in the UI. Thus, I think a those small packages should not provide any plugins to pre-existing plugin types.

Then, there is the special case of defining a new plugin type + providing some default plugins - as it is the case for the TypedData stuff of Rules (e.g. there are data filter plugins). For being able to use that plugins a module has to use the new API provide by the package, thus the module needs to require it. Given that, there is no dependency problem although there is the need to solve the general problem of #2494073: Prevent modules which have unmet Composer dependencies from being installed.

That said, I think it's ok for a package to define a new plugin type with some default plugins.

Still, there is the open question of allowing those small, re-usable packages to define services. As there is no way for them to hook into Drupal, we'd have to make a bridge module - a "Package Registrator" - which allows the packages to define services; e.g. by looking for a drupal.services.yml in the package root directory. Going with something like container-interop would be an option also, but I think the majority of those small re-usable packages will depend on Drupal anyway so a Drupal-usual way to the define the services is fine. Still, the "Package Registrator" could support other ways in future as well and/or even go further and make use of puli. But that goes further as what I want to achieve here.

But then you can just create micro modules instead that have "hidden = TRUE" in their info file to not clutter up the UI.

If your package requires Drupal anyway, then it can just be a module and we don't need some package registrator abstraction overhead.

>But then you can just create micro modules instead that have "hidden = TRUE" in their info file to not clutter up the UI.

Good point. It has some implications though:
- The module never gets uninstalled - is that a problem?
- More weight: Drupal will scan for hooks, plugins, libraries, ...
- No clear cut - the micro module could just be evil and provide some user-facing plugin?
- Confusion - why does that thing in my module folder not show up in the module list?

That said, not sure those points are enough of a drawbacks to justify the efforts of creating the distinction and "Package registrator". But in the end, I think the confusion point is the main issue with a hidden module - people are still seeing it in the file system and get confused.

https://www.drupal.org/project/typed_data - it's moved now. Still, we need to remove it from Rules and depend on the new location.

https://github.com/fago/rules/pull/473

And merged! :-)
Ran into https://www.drupal.org/node/2809337 though.