RecipeRunner::processInstall() installs modules one by one

Note we need to think about \Drupal\Core\Recipe\RecipeRunner::toBatchOperationsInstall() too

It's likely this change will result in quite a bit of refactoring.

The tricky bit here will be

    // Disable configuration entity install but use the config directory from
    // the module.
    \Drupal::service('config.installer')->setSyncing(TRUE);
    $default_install_path = \Drupal::service('extension.list.module')->get($module)->getPath() . '/' . InstallStorage::CONFIG_INSTALL_DIRECTORY;
    // Allow the recipe to override simple configuration from the module.
    $storage = new RecipeOverrideConfigStorage(
      $recipeConfigStorage,
      new FileStorage($default_install_path, StorageInterface::DEFAULT_COLLECTION)
    );

@phenaproxima suggested wrapping all the config from all the modules together. This might work because modules cannot have conflicting config - we have the PreExistingConfiguration exception that handles that. I'm concerned that it might not work because that when you install the first module it'd discover all the configuration from the modules that are yet to be installed. Not sure how that's going to work out.

+1 on the need for this. I can install the Event Platform project (which has loads of nested dependencies) in less than 20 seconds via the Drupal UI or drush. If I implement a recipe that installs this project (and does nothing else, even forcing the configuration to load) then the recipe runner tries for several minutes and then inevitably fails.

I will also add that this seems to severely impact the intended reusability of the recipes within Drupal CMS. I can include one such recipe in my own recipe (tested successfully with drupal_cms_admin_ui) but my recipe fails to apply if I add another (tested by adding drupal_cms_anti_spam, which only adds another 5 dependencies, based on the command line output).