Container / service exceptions while installed from existing config

Problem/Motivation

Issue #3544715: Add oop support to hooks currently supported by themes brought us theme OOP hooks. To do so ConfigInstaller has to rebuild the container, like ModuleInstaller does.
What was forgotten there was duplicating the ::reinjectMe() codepath from modules to themes too in the ConfigImporter.
The result: All sorts of likely hard to spot container DI issues on cli install, likely breaking the install (thus major).
- This report: retrieving a synthetic service ("kernel") throws
- the other report (#3569677: 3544715 breaks RequestStack on existing-config-install): some services have an empty RequestStack

Steps to reproduce

1. Prepare a site with an existing configuration export.
2. Ensure the configuration includes items that trigger theme-related updates. In our case, this error is triggered when webform.webform_options.* (provided by the Webform module) is being imported.
3. Run the installation command: drush site:install --existing-config

Proposed resolution

In ConfigImporter, do the same container rebuild handling for themes that is done for modules.

Remaining tasks

- Write a test
- ConfigImporterTest seems to be the place for it. This class currently has no test for the ModuleHandler ::reinjectMe code path.
- There is ::testInstallBaseAndSubThemes though, which might be nice to extend.
- Test inspired by this report: $container->get('kernel')
- Test inspired by the dup report: $container->get('request_stack') ... contains request
- Decide whether that other line from the module codepath must be duplicated and tested too: $this->moduleHandler->loadAll();
- review, commit, stop having pain

Original report

This issue occurs in Drupal 11.3.1, while it does not occur in Drupal 11.2.10.

When performing a non-interactive installation from existing configuration (e.g., using drush site:install --existing-config), the following error may occur during the configuration import process:

You have requested a synthetic service ("kernel"). The DIC does not know how to construct this service.

In Drupal 11.3, the ThemeInstaller (theme_installer service) was updated. It appears that DrupalKernel::updateThemes() now triggers a container re-initialization.

Within ConfigImporter::processExtension(), after the theme_installer service is executed, it seems necessary to re-inject the services (similar to how it is handled for modules) to prevent the service container from losing track of synthetic services like the kernel.