Make menus easier to customize

[ybnd]

Problem statement

Back in #1627 we moved the menus used for the header navbar and admin sidebar to a single class: MenuResolver
Later on we created a similar resolver to treat the various buttons on Community, Collection and Item pages as another menu for consistency: #2385

These resolvers were an improvement in the sense that they neatly separated the content of the menus from the components that are responsible for rendering them.

However, they also introduced a number of hurdles:

• To add new a menu section to a custom DSpace instance, developers can either
  • Add it to src/app/menu.resolver.ts itself, and sacrifice
    compartmentalization between standard DSpace code and custom code
  • Extend the class, override a method and add it there
• Things get trickier if you maintain a subclass of MenuResolver and want to remove or modify a particular menu section
• The resolvers have reached a "god class" status and are unwieldy to work with

Furthermore, route-dependent menu entries are often duplicated between routing modules and cannot support much of the functionality available to standard menu entries by design.

Proposed solution

• Move related menu sections to small, dedicated MenuProvider classes
  • For example, the Add and Edit menus in the admin sidebar become AddMenuProvider and EditMenuProvider
  • Developers that wish to modify what appears in those menus can swap out these providers for another class or leave them out altogether
• A single MenuProviderService calls upon all MenuProviders assigned to a given menu and pushes its content to the store
• MenuProvider implementations can be route-dependent
  • In this case, the provider can be "registered" with the MenuProviderService, but not injected into the menu at startup
  • Instead, routing modules specify which MenuProviders should be active on a particular route