Standardise our context menus

[maltenuhn]

This is partially an investigation task to 'take stock' of what we have, how it's implemented, and how it needs to be refactored.

Problem
Our "context menus" are non-standardised, hard to implement quickly, and even harder to fix because of the 'which one' problem. But they are also on the critical path to expose capabilities quickly, and in a way that is not embarassing.

What do we want?

1. An easy, fast, and standardised way to create a new "Popout" menu:

• to populate: either with a "list of things you can click on", or a completely custom UI,
• and that's correctly positioned vs the element invoking it. (NB sometimes that element is a button - probably SquareButton -, sometimes it's something more custom like an avatar)
• if it's populated from data, that data / labels possibly need to be contextual ('Show Inspector' vs 'Hide Inspector', disabled entries etc
• a way to invoke this that doesn't require adding the new menu to a bunch of places

Some examples of things we've talked about

• Avatar that shows "Show Projects", "Add Github authentication" and "Log out"
• the new Component Picker and Data picker menu, but correctly positioned (!)
• A "Panel" button in the toolbar that shows what panels are shown and hidden
• A "..." SquareButton in the Component part of the inspector, with options "Jump to component definition" and "Jump to source"
• The 'add Page' button correctly tied to the Plus button (btw check out how this was incorrectly implemented using the item-context-menu because that was the easiest to find

2. An easier way to specify the missing 'Pages tab' context menus for routes and favorites ('Remove from Favorites', 'Add to Favorites', 'Jump to source', 'Copy URL')

3. Cleaner, more modular, more modern code, and standardised keyboard handling across the editor for these

4. 4. Standard styles for Menu Entries, including the common variants:
      (a) just-items (no space for icons),
      (b) some-or-all-elements-have-icons,
      (c) w/ optional space for optional keyboard shortcuts or accessors, and
      (d) with indentation and expansion arrows
      (e) the 'checkbox' version we have in PopupListControl

NB those Menu Entries are also eerily similar to List Items elsewhere! Please propose ways to standardise these more, universally (cf the implementation of <GridRow variant='... that we really like)

This is probably 40% investigation, 15% implementation, and 78% refactoring

FAQ to get you started

How are context menus implemented?
In a number of ways, mainly by using a legacy React Contexify and then building a wrapper for it, but also in other, more surprising, ways. They've accrued over the years!

What context menus do we have today?
(no guarantee this list is exhaustive)
Actual context menus, contextual to selection and invokable / positioned on right-click

1. selected elements (try it on the canvas, or in the navigator)
2. files, in the file browser

Pseudo context menus - right click, and positioned there
3. The context menu on the actual canvas (right now containing precisely one option)

Popout Menus
(is there a standard UI term for these? these are invoked by buttons or keyboard shortcuts, and should be correctly positioned underneath the button - or in a specifiable location)

4. The new Insert menu
5. The new data picker
6. the Add-Page context menu
7. Arguably, the font picker

PopupMenuControl
This is a classic list, but with the selected element in the list showing in the place where the UI control is. This is implemented entirely differently on top of React Select. We should replace it eventually, but out of scope here:

_We also have popover Panels: These are still contextual to a UI element, but less "menu-like" - eg the Fill picker or the Shadow picker.