Make toolbar items first class menu citizens

Follow-up to #2784589: Provide a method for module to specify that their toolbar items should appear in Edit mode

Problem/Motivation

Currently hook_toolbar is used to control toolbar item presence on particular pages. This hook is relatively under-powered and has a number of problem within it.

1. The hook assumes that all items within it are global in scope.
   The hook is executed on each page to determine caching each time, so it is possible for it have different items per page, but in order to do this, a significant amount of logic has to be built into the hook itself for a given implementation. In the case where a menu item is available on canonical links of certain entity types given a set of criteria, the hook has no knowledge of the current route match nor any mechanism by which to couple routes to implementations within hook_toolbar. The net result is that menu systems like local tasks are much more robust and able to do things like properly respect route enhancers and other routing level objects that need to execute in order to inform the menu system of access/visibility of menu items.
2. The hook is functionally building a render array.
   The expected return value of hook_toolbar is a render array. This seems problematic in and of itself but is especially jarring juxtaposed with D8's other apis. It feels like a real return to Drupal 6/7 style code. This is further problematic because each implementor of hook_toolbar has to manually apply things like AccessResult cacheability metadata to the render array rather than allowing the system to calculate that information appropriately based upon routing data.
3. Toolbar modes aren't an actual thing.
   Reading a bit in the issue queue, and just actively using this system reveals a base-line assumption that there is such a thing as an "edit mode"
   of the toolbar, but this is not the case at all. Instead, the quickedit module's edit button has been hijacked by outside_in module and various menu items which don't have the appropriate data element on them are magically hidden when quickedit is activated. This is especially problematic imo because I actually understood what was happening at one point, but outside_in's approach conflated "edit mode" as a concept with "quickedit" as a functional thing. This is made more difficult because the menu items in the toolbar don't change so much as a subset of them are just exclusively displayed now.

Proposed resolution

1. Introduce toolbar items as a top level menu api akin to local_tasks.
   We'll have to continue supporting hook_toolbar for BC purposes, but giving a new yaml file and plugin solution to building toolbar items would be a big boon. I'm pointing to local_tasks because they support a notion of parenting which allows us to programmatically calculate sub-routes and do things like execute access methods in order to determine visibility. This should remove the need to write raw render array output AND streamline the creation of new toolbar items.
2. Determine if toolbar modes are something we want to actively support.
   I'm personally in favor of the idea of toolbar modes, but we continue to discuss them as though they're something we support, and looking at the code, they're clearly not. If we want toolbar modes, let's build such a feature.

Remaining tasks

• Discuss
• Patch
• Iterate

User interface changes

• This could introduce a toggle or even mode selector within the toolbar. TBD

API changes

• Introduction of new top level menu api for building toolbar items instead of raw render arrays in a hook.
• Will need to maintain BC