Improve 2nd level horizontal menu behaviour

Based on discussion with @Berdid, @sasanikolic and @jzech here is a new patch. I've added a new theme option 'Overlay second level' with the next values:

• 'Off' option - we will reserve space for the horizontal second level if some top menu level item has second-level items.
• 'When not active' option - we will reserve space only when active menu item has second-level menu items, and when not we will show the second level overlayed.
• 'Always' option - we will never reserve space and always show the second level in the overlay.

'Off' option is a default one and this is how second-level horizontal menu was behaving for now. The 'When not active' option is the one we discussed. Then adding 'Always' overlay option was my addition.

Found some additional problems, actually cases that are not well covered. I think this is connected with changes in \Drupal\system\Plugin\Block\SystemMenuBlock::build() so reapplied those changes here.

Also, we do not need any more `$navbar-2nd-menu-bg`, it is replaced with newly introduced `$navbar-2nd-bg`, so we can remove it.

Copy&pasting that code from `SystemMenuBlock::build()` is maybe a bad thing? If something changes again later it can hit us here. Also, code is becoming bigger and more complex in `bs_bootstrap_preprocess_page()`. Howe about we maybe just call that `SystemMenuBlock::build()` method instead of duplicating that code? Here is a patch that does that, seems it works fine.

Found some additional layout problems when both first and second levels have bottom borders.

Damn, found one more, we do not need `$configuration['expand_all_items']` any more (from previous refactorings) and it is not needed any more, plus it creates problems. Removed it.

The last patch got uploaded wrong somehow, here is a correct one.

+++ b/themes/bs_bootstrap/bs_bootstrap.theme
@@ -228,27 +245,46 @@ function bs_bootstrap_preprocess_page(&$variables) {
       // Lets first check that block is a menu block and it is displayed.
       if ($plugin->getBaseId() == 'system_menu_block' && $block->access('view')) {
-        $menu_name = $plugin->getDerivativeId();
         $configuration = $plugin->getConfiguration();
 
-        $parameters = $menu_tree->getCurrentRouteMenuTreeParameters($menu_name);
-
-        // Adjust the menu tree parameters based on the block's configuration.
-        // @see \Drupal\system\Plugin\Block\SystemMenuBlock::build().
-        $level = $configuration['level'];
-        $depth = $configuration['depth'];
-        $parameters->setMinDepth($level);
-        if ($depth > 0) {
-          $parameters->setMaxDepth(min($level + $depth - 1, $menu_tree->maxDepth()));
-        }
-
-        // Check is second level active.
-        $tree = $menu_tree->load($menu_name, $parameters);
-        foreach ($tree as $menu_item) {
-          if ($menu_item->hasChildren && !empty($menu_item->subtree)) {
-            if ($navbar_onhover || $menu_item->inActiveTrail) {
-              $variables['navbar_second_level_expanded'] = TRUE;
-              break 2;
+        // Load a menu block and build its menu items.
+        $menu_block = new SystemMenuBlock(
+          $configuration,
+          $plugin->getPluginId(),
+          $plugin->getPluginDefinition(),
+          \Drupal::menuTree(),
+          \Drupal::service('menu.active_trail')
+        );
+        $menu_block_build = $menu_block->build();
+

$plugin is exactyl the same thing as $menu_block, you don't need to create that, you already have an instance of that block with the correct configuration.

Note that you must never instantiate a plugin like that manually, always use the plugin manager service, because those arguments might change over time.

FWIW, the overall approach isn't great for performance, because we have to load, process and prepare the menu twice, and this runs even if the blocks themself are render cached. But I don't really have an idea to handle that better.

Also, the get base id check isn't perfect, it's possible that custom block plugins are used for this, we have projects like that (which then dynamically decide on the menu to display), but sadly there is no way to detect a block that will render a menu any other way I think.

At most we could make the plugin id(s) configurable, but we can consider that when we need that.

@berdir thank you for your review, here is a new patch based on your comment. Tested everything one more time, seems it is working OK.

The latest patch needed a small change because we removed the lazy loading option in favour of core handling this.

Committed.