feat(console): help view modal

[hds]

Adds a help modal which is available on every view. The help help modal
can be accessed by pressing ? and overlays the current view. To leave
the help modal, the user can press ? or Esc.

This PR is based on #243 originally authored by @bIgBV. The previous PR
has been dormant for around a year.

Currently the help modal only displays a vertical list of controls. This
is the same information that is available in the controls widget on each
view.

Here is an example of the tasks view with the help view modal active:

connection: http://localhost:6669/ (CONNECTED)
views: t = tasks, r = resources
controls: select column (sort) = ←→ or h, l, scroll = ↑↓ or k, j,
view details = ↵, invert sort (highest/lowest) = i, scroll to top = gg,
scroll to bottom╭Help──────────────────────────────────────────╮t = q
╭Warnings───────│controls:                                     │───────────────╮
│⚠ 1 tasks have │  select column (sort) = ←→ or h, l           │               │
╰───────────────│  scroll = ↑↓ or k, j                         │───────────────╯
╭Tasks (12) ▶ Ru│  view details = ↵                            │───────────────╮
│Warn  ID  State│  invert sort (highest/lowest) = i            │t      Location│
│       19 ▶    │  scroll to top = gg                          │::task console-│
│       22 ⏸    │  scroll to bottom = G                        │::task console-│
│⚠ 1    23 ⏸    │  toggle pause = space                        │::task console-│
│       24 ⏸    │  toggle help = ?                             │::task console-│
│       25 ⏸    │  quit = q                                    │::task console-│
│       74 ⏹    │                                              │::task console-│
│       75 ⏸    │                                              │::task console-│
│       77 ⏸    │                                              │::task console-│
│       78 ⏸    ╰──────────────────────────────────────────────╯::task console-│
│       79 ⏹      wait      11s    4ms   56µs    11s 2     tokio::task console-│
╰──────────────────────────────────────────────────────────────────────────────╯

However, the idea is that the help modal can provide contextual
information depending on the view and the state of the application being
observed. This will allow us to provide more details about any lints
which are currently triggering and also to reduce the height of the
current controls widget to just one line (perhaps optionally) as the
full list of controls can be accessed from the help view.

Co-authored-by: bIgBV bhargav.voleti93@gmail.com

[hawkw]

thanks for working on this! i had one suggestion for potentially simplifying the implementation a bit, but i'm fine with the current approach if you think it's better.

[hawkw]

nit, take it or leave it: I'm not 100% convinced that the HelpText trait is really necessary here...couldn't we just have the help_text variable be a Paragraph, and have each view type have an inherent help_text() method that returns a Paragraph?

[hawkw]

i guess the advantage of this approach is that we can assign help_text in the same match expression as rendering the view without having to actually allocate to build the paragraph if we're not displaying the help text. but, we could alternatively just put an additional match in the if self.show_help_modal block, which would call the current state's method to get a Paragraph of help text...

it's up to you whether this is actually better, i think the trait is fine, i just don't know if we really need it.

[hds]

My idea with the trait was to eventually do the same for the main view. It seemed like it would simplify things if we could return an object that implements MainView + HelpView or something like that and then render one or both depending on context.

I don't know if this is overengineering things though.

[hawkw]

My idea with the trait was to eventually do the same for the main view. It seemed like it would simplify things if we could return an object that implements MainView + HelpView or something like that and then render one or both depending on context.

I don't know if this is overengineering things though.

That makes sense! If you're planning on continuing down this path in a subsequent PR, I think adding the HelpView trait now seems reasonable. If we try out a trait-object-based design and it doesn't work out, we can always change this code later, but I'm fine with merging this PR as-is.