Convert navigation sections to blocks and use the menu system

Yesterday, we had a call reviewing this with @ckrina, @laurii, @ted.bowman, @tim.plunkett, and myself, along with some followup chats.

This is from my own notes on the call, feel free to comment if I misrepresent anything!

In terms of functionality, site builders:

• Should be able to customize the links in menus, just like they can today.
• Should be able to add brand-new menus that they create from scratch, or menus from other modules.
• Should be able to reorder menu blocks themselves.
• Should be able to add non-menu blocks to the green content area in this screenshot, as long as those blocks have been explicitly tagged somehow as being navigation menu compatible. For example, we could easily imagine site builders wanting to somehow put a list of recently edited content int the menu. While we wouldn't want to expose all Views blocks by default, once we have a way to mark those blocks as good in the nav menu we want site builders, and not developers to be able to manage them.

Developers:

• Should be able to customize the top region and the bottom region, for modules like Workspaces or Environment Indicator.

From a technical perspective, this is actually the first time plugin implementations have been subclassed in core. @tim.plunkett pointed out that there's real dragons as far as backwards compatibility goes, especially with constructors. There are instances of contrib modules doing this (like superfish), but in practice we may make things simpler and just ditch the whole aspect of subclassing. As well, it may be easier to alter in additional block annotation properties than to try and do an entirely separate annotation type.

We also discussed shipping a single block plugin that renders other blocks, instead of literally deriving block plugins.

For next steps, I would like to:

• Implement an example integration for a core module like Announcements or Workspaces.
• Use that to learn what makes sense as far as the existing "as block plugins" approach goes.

I've redone how the plugins are handled and I'm much happier with the approach. IMO it's simpler and more robust.

Instead of a separate annotation, we now look for navigation on the normal Block annotation. I've defined it as an array, so we can add keys like default_region, weight, and so on. To do this, we add our own plugin manager that wraps the block manager (it's not really decoration because we don't swap the service). It handles filtering available plugins and validating the additional keys.

Then, I implemented the announcements feed as a demo block. An interesting side effect is that the Announcements menu item works as is, showing the dialog of announcements on the left hand side.

For next steps, it would be great for someone else to look at what I've done with the navigation block manager and share any compatibility concerns or similar I may have missed.

To followup and summarize on next steps for this:

There's some skepticism that it will be possible to have a single block implementation that can ever work in both a navigation and non-navigation context.
The block system has intentionally been designed to not include any sort of real rendering context in the `build()` method.
There's also some worry that if there are separate blocks implemented to handle these cases, that the regular block admin could have duplicate blocks.
While Blocks have a context system (\Drupal\layout_builder\Plugin\Block\ExtraFieldBlock does this to associate an entity object), in practice they are best used for data and not theme or rendering information.

A good next step would be to walk this back to having a separate plugin implementation, _but_ still have Navigation blocks implement or extend \Drupal\Core\Block\BlockPluginInterface. That interface already defines most of what we need for navigation blocks, and would provide a familiar pattern for contrib modules to implement navigation support, or to more easily extend and share code for existing blocks if it does make sense.

Thanks Prashant! I see two next steps depending on your comfort and interest.

1. Create an issue that does nothing other than create the Content menu, and pull the related code out into that. Don't even worry about displaying the menu; let's just get a menu for Content in that we can reference in future work.
2. Change the current plugin implementation back to having a totally separate plugin manager from Blocks. Our plugin type should still require that they implement or extend \Drupal\Core\Block\BlockPluginInterface. But, the discovery, namespace, and directory should be separated out again.

I've had some things come up that will limit my availability for this, so I'm really glad to see you here offering to help. Thanks!