Rename 'module_handler' service and ModuleHandler classes

Aight. ;) That "circular" is what actually caused me the most headaches when working on the module_handler patch. :-D

Add to that, DrupalKernel additionally manages a list of active modules in %container.modules%. That caused me even more headaches. ;)

So if we'd map the current conclusions, then we'd end up here:

1. A kernel builds a container, based on a list of modules. (DrupalKernel)
2. A hook-based event dispatcher gets the list of modules injected by the kernel. (ex. module_handler)
3. A module manager gets the config service injected by the kernel to install/uninstall/enable/disable/persistently-sort modules. [new]

Note the difference on the currently active module list (provided by the kernel) and the configured list of enabled modules (in config). That's highly important:

A module manager service would mainly/only operate on the configuration, and its main purpose is to change the actively participating extensions in the application — in essence, changing the kernel's build parameters. (If we wanted to do Symfony [CMF] a favor, then we'd architecturally design that service in a way to be able to cope with arbitrary PSR-0 components, instead/in-addition of just Drupal modules.)

That said, what's still missing in this puzzle is the moduleExists() method. Right now + in the past, module_exists() is/was based on the currently active module list only. As such, it would actually map closest to %container.modules%, because we're not talking about hooks, and we're also not really talking about the configured list of enabled modules. module_exists() (outside of the hook system) actually asks whether a module is currently active (in a rather undefined way). So with a fixed module list (as in install.php or update.php), it actually returned TRUE when asking for e.g. system.module ('cos it's in the currently active module list).

However, if we decide that moduleExists() should be bound to the hook system, then I think I'd be down with that. From all possible (but unknown) meanings, that probably comes closest. :)

Yeah, I agree with #3.1, and I was probably shooting for too much.

re: #3.2, since the current meaning is undefined, we can go either way. If we detach it from the hook system, then I wonder whether it wouldn't actually fit best on DrupalKernel?

That is, because I think that the new service for #1893690: Find a new home and service for module_enable(), module_disable(), module_set_weight(), etc should *only* deal with operations that change the configuration of the application; i.e., module_enable(), module_disable(), module_uninstall(), module_set_weight(), etc. — In other words, you only use that service if you want to change the configuration of the system.

Compared to that, module_exists() just asks whether a given extension is currently active. "Active" would have to be defined:

1) In the active list of modules whose services are available and whose code is loaded and executed.

2) In the list of configured, enabled modules. (But not necessarily active/loaded right now.)

Perhaps we can just do both, in which case

1) would be DrupalKernel::moduleExists()

2) would be ModuleConfigurator::isEnabled()

ModuleHandler::moduleExists() would cease to exist, since the question is not related to hooks.

Would that make sense?

Also, work on the follow-up patch #1894910: Move module_invoke() into ModuleHandler revealed:

There's a stale @defgroup for the module/hook system in module.inc, which explains its architecture and usage. So if we rename module_handler to be the hook system, then we should probably move those docs entirely into the class phpDoc of ModuleHandler[Interface].

The more I think about this, the more it makes sense to me. Apparently, the Hook system isn't really limited to modules; e.g., [drupal_]alter() checks for hook implementations in themes, too. I actually wanted to remove that separation/limitation entirely for quite some time already, and simply invoke hooks in all extensions. That is, because the artificial limitation to "only modules and a tiny bit of themes" requires tons of ugly, custom code in single spots, and isn't consistent at all (you know... hook_theme() is not an alter hook, but yet, invoked in themes...). So, alas, I expect the overall code to become much more simple if that special-casing was removed entirely. I'm working on converting theme registry into service already, and I might get to that afterwards.