Add "Help" entry to menu bar to show keyboard shortcuts dialog

[keysmashes]

This should, hopefully, make it fractionally easier for people to discover how to actually do anything. (If they realise that the menu bar is clickable.)

Related: #25

[emesterhazy]

I think that realizing the menu is clickable is the biggest hurdle. It never occurred to me to click it until someone told me that it's possible on the issue tracker.

Two ideas:

1. What if instead of "Help" we are more explicit and write "Click for Help" or something? It's a bit uglier, but probably way more helpful.
2. Is it possible to make clicking the help item open the help menu directly? Requiring a second click doesn't serve any useful purpose, but I'm not sure how flexible the menu system is.

[emesterhazy]

We also need to update the changelog in this commit :)

[keysmashes]

I think that realizing the menu is clickable is the biggest hurdle.

That lines up with the experience I heard which prompted this PR! It's certainly not a particularly common UI for terminal applications.

What if instead of "Help" we are more explicit and write "Click for Help" or something? It's a bit uglier, but probably way more helpful.

I was considering adding some note that disappears once you've opened a menu at least once, like this:

[File] [Edit] [Select] [View] [Help] <-- click here!

but calling the menu entry [Help (click to open)] would be much easier, I'll do that.

Is it possible to make clicking the help item open the help menu directly?

Honestly I made the change this way mostly because it was so easy, given the existing event to open the help popup. I think it would be possible to adjust <MenuBar as Component>::draw() (or possibly Recorder::click_menu_header() or Recorder::get_menu_item_event()?) to support Menu entries dispatching an arbitrary event directly? But...

Requiring a second click doesn't serve any useful purpose,

I was wondering about also adding an About item to the same dropdown, which would open a different dialog that could look something like this:

┌About─────────────────────────────────────────────┐
│                                                  │
│ This UI is part of the `scm-record` library,     │
│ which provides the `scm-diff-editor` executable. │
│                                                  │
│ https://github.com/arxanas/scm-record            │
│                                                  │
└───────────────────────────────────────────(Close)┘

because at the moment, it's almost impossible for a user to figure out what's actually responsible for the thing they're seeing, unless they stumble across e.g. the single mention the Jujutsu docs make of scm-record.

[emesterhazy]

Adding an about section sounds like a great idea. That way people can direct their feedback here instead of the jj repo. Want to add that and update the menu item name? I think updating the name is the simplest thing to do for now since we don't have a config file or any obvious way to remember that the user has clicked the menu at some point.

Edit: I forgot to say that the about section can be a separate commit / pr. It doesn't have to be done in this one.

[keysmashes]

I was going to say that tackling that in a separate PR sounds good, but I started poking at it and ended up with an implementation :)

It's not super tidy, there's plenty of duplication between the existing Help dialog and the new About one (on account of the latter being set up by copy-pasting everything relating to the former), and you can get into a slightly wonky state by trying to open both at once:

I guess that's fixable by tweaking the handlers for StateUpdate::Set*Dialog to set the other dialogs to None if the passed dialog isn't None... (which makes me wonder: can you get into this state already with the Quit and Help dialogs? the answer is yes)