Key panel widget

[willmcgugan]

Adds a KeyPanel which can be summoned via the command palette.

[darrenburns]

Isn't this subject to the same issue as what we discussed earlier regarding having the first option always highlighted by default? If they can come in asynchronously, then when the user presses enter there may only be 1, but this doesn't mean there will always be one.

I think in VSCode and the browser URL bar, it also does things asynchronously, but it just selects the one that was at the top when the user presses enter.

[willmcgugan]

That does introduce a 100ms window where something could change. I'll see if I can remove that.

[willmcgugan]

I've removed the timer for now. In a future update, I'll implement the logic to highlight the first item.

[willmcgugan]

#4902

[darrenburns]

Looks good and works well. I made a few suggestions which I don't think need to be part of this PR, but would be nice to create tasks for and tackle relatively soon IMO (otherwise they'll end up forgotten).

[darrenburns]

Also want to suggest that we have some way of showing which "level" of the DOM keybindings belong to. This sidebar looks a bit confusing in Posting for example, because I can't tell which widget a binding belongs to.

e.g. I have a binding called Expand section. If I have the Tree focused, it's not clear if that means "expand the current node of the tree", or "expand the tree section of the overall app". I think if they were somehow grouped with the widget name (if available) or something it'd be easier to read in large apps with many bindings (where the key panel is itself most beneficial).

Example from the lazygit UI which has two levels: local and global...

[darrenburns]

Another thing that I just noticed in the lazygit popup is that you can click the bindings and it runs the action, similar to our Footer widget.

[willmcgugan]

#4904