Improved, structured top-level app navigation

[amcclain]

We've implemented a pattern like this in several applications, but it would be great if we could capture within Hoist, ideally in a backwards-compatible way.

• Client Apps should be able to emit a data structure to define their top/module level navigation - the main routable tabs / sub-tabs they will present to the user - in a hierarchical way, or at least a two-level hierarchy.
• Each top-level route can either be an actual module, or a parent route that holds a collection of child modules.
• An app-level tab container would be created to host each top-level route, with either an actual module tab inside or another nested tab container to render the child module tabs.
• A new "tabSwitcher-ish" component could be used in the top AppBar.
  • For top-level routes that are modules, there is no drop-down - clicking it will go there
  • For top-level routes that have child routes, a drop-down menu could show on hover and allow the user to choose what route to go to.
    • Consider a feature where the user can also click on the top-level menu item in this case, which will take them either to the first/default child (if no children in the group have been mounted) or take you to the last visited tab (if you have been there before). Believe that would provide parity with the current two-level tab nav we commonly use - eg in Hoist Admin Console.
• The nav data could then be used to generate appropriate routes without devs needing to spec that boilerplate and ensure it aligns with the tabs that have been actually defined.
• It could also be used to power a "go-to" omnibox style nav, either something we build in as an option with a hotkey or - if we don't do that - something that devs can make themselves
• Support for omitting routes should of course be built-in - we could consider something like AppSpec.checkAccess where we have a shortcut for defining required roles, or any custom closure