Refactor and fix focus management

[kasbah]

This is largely a refactor of focus and keyboard shortcut management (closes #161). It also:

• Implements shortcuts for undo/redo (supersedes Keyboard shortcuts for undo/redo #1186)
• Fixes Keyboard navigation of cells interrupted by completion popup #1256 as best we can without changing completions to not to use up/down: when doing keyboard navigation you might sometimes have to Esc out of a completion popup.
• Fixes Focus seems wrong when opening analysis tab #159
• Adds focus indication to the side-bar:

[epatters]

Thanks for undertaking this refactor. Focus management has been a longstanding problem, and I'm glad we're thinking through a design for it instead of piling on hacks.

There may well be subtleties that I'm overlooking, but the present design is more centralized and specific to notebooks that I would have expected. As the comments in type.ts explain, the application-level focus state says not only which notebook is focused, but which cell and even which popover in the notebook is focused. I have several worries about this design:

1. It is specialized to notebooks, but we will have documents that are not notebooks
2. It leaks information deep in the component hierarchy up to the application top-level
3. It conflates data and layout: focus is attached to notebooks by ID, rather than to panes

To focus the mind, consider the concrete scenario of integrating a Petri net editor into CatColab (cf. #1279). Such an editor will need to get and lose focus coherently with the rest of the app.

I'm trying to imagine a more compositional/hierarchical approach, where a component tracks which of its immediate children has focus. We're already kind of doing this in the notebook and object/morphism editors, e.g., a notebook keeps track of which cell is focused. I propose doing the same thing one level up: the document page should keep track of which of its 1-2 panes has focus. In this approach, focus changes bubble up the component hierarchy, e.g., when a name field in a morphism editor gets focus, it notifies its cell that it has focus, which notifies its notebook, which notifies the document page. In this way, a component pushes its focus events upward.

To handle keyboard shortcuts, components must also be able to "pull" the latest focus state, since another component may have grabbed it. To do so, one must walk up the component hierarchy again, asking if each parent has focus. I would imagine this pulling and pushing could be handled by passing a getter and a setter for focus state.

What do you think?

[epatters]

Exciting to finally be rid of this hack!

[kasbah]

I've introduced a FocusHandle and a useChildFocus that handles the recursion into parent components. I believe this implements your idea as described and seems to mesh better with the rest of the code than my previous design.

[epatters]

Thanks Kaspar! The way you've set up the new FocusHandle abstraction is quite elegant IMO.

[epatters]

It's great that the new design avoids having to handle this tricky logic across a bunch of individual components.