Extension System, Part III: ExtensionList/ExtensionHandler

1. The "list" of extensions defines the list of enabled/installed extensions.
2. There is a list for each extension type: profile, module, theme, theme_engine.

3. The installation profile

   1. is defined as $settings['install_profile'] in settings.php (but only its name)
   2. is added to the list of enabled modules with a weight of 1000 in drupal_rebuild_module_data()
   3. is contained in the %container.modules% parameter on the service container

   There is a second"parent" installation profile when a test is executed, which

   1. is defined as $config['simpletest.settings']['parent_profile'] in config/settings.php (only its name)
   2. is NOT added to the list of enabled modules
   3. is NOT contained in the %container.modules% parameter of the service container
   4. is only used by ExtensionDiscovery to additionally find extensions in the parent installation profile, from which tests were executed.

4. The list of enabled modules

   1. is maintained by ModuleHandler::install() and ModuleHandler::uninstall()
   2. is stored in the core.extension configuration object
   3. is contained in the %container.modules% parameter on the service container
   4. can be manipulated at runtime (without touching configuration) via ModuleHandler::setModuleList()
   5. is consumed by system_rebuild_module_data() to enhance module info with a $status property reflecting the installation status

   Aside from that and the system_rebuild_module_data() aspect, management and maintenance of the module list is pretty clean already.

5. The list of enabled themes

   1. is maintained by ThemeHandler::install() and ThemeHandler::uninstall()
   2. is stored in the core.extension configuration object
   3. is consumed, enhanced with theme info, and cached by system_list()
   4. is consumed by system_rebuild_theme_data() to enhance theme info with a $status property reflecting the status (whereas there is no installation status yet)

   Except of the core.extension:theme configuration, this list factually does not really exist on its own right now — it is deeply intertwined with theme info currently.

   The list is also not stored in an efficient way like the %container.modules% parameter on the service container; i.e., the system always has to consult the configuration system to retrieve it.

6. The list of theme engines

   1. does not exist at all.

   ThemeHandler::rebuildThemeData() blatantly performs an ExtensionDiscovery to simply retrieve all available engines.

Proposed solution

1. Provide a common way to list extensions (enabled and not enabled ones)

   → Central data source for ExtensionList (ModuleExtensionList, ThemeExtensionList, ...)

2. → Provide common methods for e.g. resolving dependencies

   → Use it directly for profiles and theme engines.

3. Try to untangle at least some of the theme list/data/info mess.