Remove potential support for engine-less themes

I've created a theme with an info file like so:

name: Zero
type: theme
description: 'An intentionally plain theme with no base theme or theme engine.'
package: Core
version: VERSION
core: 8.x
base theme: false
engine: ''

I also did engine: false

The result in the UI was this:

However via drush...

sudo -u _www drush then zero                                              409ms  Thu 13 Dec 09:30:04 2018
 [success] Successfully enabled theme: zero

hmmm...

So even if you use Drush to install such a theme and then use drush to set it as the default theme... then there is no engine but there also cannot be an owner because owner is set liek this:

     // Defaults to 'twig' (see self::defaults above).
      $engine = $theme->info['engine'];
      if (isset($engines[$engine])) {
        $theme->owner = $engines[$engine]->getExtensionPathname();
        $theme->prefix = $engines[$engine]->getName();
      }

And without an owner nothing is going to happen here:

      // include non-engine theme files
      foreach ($active_theme->getBaseThemes() as $base) {
        // Include the theme file or the engine.
        if ($base->getOwner()) {
          include_once $this->root . '/' . $base->getOwner();
        }
      }
      // and our theme gets one too.
      if ($active_theme->getOwner()) {
        include_once $this->root . '/' . $active_theme->getOwner();
      }

So for me this is truly dead code.

In system controller we do

        // Confirm that the theme engine is available.
        $theme->incompatible_engine = isset($theme->info['engine']) && !isset($theme->owner);

We just don't support a theme without an engine and thereby an owner.

We could add

    // Ensure we have an engine. Setting engine to FALSE or an empty string is
    // not supported.
    if (empty($info['engine'])) {
      trigger_error("Theme's with no engine are not supported");
      $info['engine'] = 'twig';
    }

to \Drupal\Core\Extension\ThemeExtensionList::createExtensionInfo() to catch the case where someone has hacked a theme with no engine to be installed. But doing that will prevent the "This theme requires the theme engine to operate correctly" message in the UI. So I'm not really a fan of that... so what I've done is to add this only if the theme is installed.

Nice - of course we do have a place where we have a theme without an engine! kernel tests with no theme... so that falls back to

    // If no theme could be negotiated, or if the negotiated theme is not within
    // the list of installed themes, fall back to the default theme output of
    // core and modules (like Stark, but without a theme extension at all). This
    // is possible, because loadActiveTheme() always loads the Twig theme
    // engine. This is desired, because missing or malformed theme configuration
    // should not leave the application in a broken state. By falling back to
    // default output, the user is able to reconfigure the theme through the UI.
    // Lastly, tests are expected to operate with no theme by default, so as to
    // only assert the original theme output of modules (unless a test manually
    // installs a specific theme).
    if (empty($themes) || !$theme_name || !isset($themes[$theme_name])) {
      $theme_name = 'core';
      // /core/core.info.yml does not actually exist, but is required because
      // Extension expects a pathname.
      $active_theme = $this->getActiveTheme(new Extension($this->root, 'theme', 'core/core.info.yml'));

      // Early-return and do not set state, because the initialized $theme_name
      // differs from the original $theme_name.
      return $active_theme;
    }

We can set up the engine here.

Discussed with @catch in slack. We agreed that having a CR here is noise as it is very unlikely someone is running a site with a theme without a theme engine. We also agreed to trigger a real warning in ThemeExtensionList to tell sites that they are in this state. For theme the fix is to make engine: twig in their template.

Now with an engine the core theme messes up the registry so we need to special case that.

Looks like I went one step too far...

Final fix I think. Something very very interesting going on in low level layout stuff in Kernel tests.

Oh weird... HEAD \Drupal\Tests\layout_discovery\Kernel\LayoutTest does not pass for me. So the patch in #12 will be green. Re-uploading that one.

Opened #3020388: \Drupal\Tests\layout_discovery\Kernel\LayoutTest passes on DrupalCI but not locally for the weirdness in #13/#14

@borisson_ I discussed this with @catch and we agreed to trigger a non silenced E_USER_WARNING here. Just haven't updated the patch yet.