feat: improve help

[DeH4er]

Linking discussion #2710

This is roughly what the help panel looks like. I didn't add all apis and I'd need some help here since I'm not aware of some functionality.

It shouldn't change drastically how users write on_attach. The only thing is that they don't need to pass eg. nvim-tree: Open in opts and it'll catch up if they use api.x.y function. If they pass a custom function as a keybinding, currently it'll not be displayed in help panel

[alex-courtis]

This is looking good - the layout is logical and discoverable.

I'm assuming that this will be another s mode, as we don't want to break users that expect the current layout. We can, however, add the actual api functions to the existing s modes.

[alex-courtis]

The groupings are almost broken up as per the 10 API groups: tree, fs, marks etc.

In the interest of simplicity and maintainability we should use those groupings, being consistent with help etc.

That feeds into the next comment.

[alex-courtis]

There is too much boilerplate code configuration here and it's not going to be very maintainable. We were in such a place before we completely moved to on_attach and it caused difficulties.

Rather than using boilerplate we can be lazy and do something like walking the Api tree. We can generate strings like validate_options does and map the functions themselves to the vim mappings. We could create a small table that maps Api.xxx to a human readable header.

Goals:

• no change to api.lua
• no change to keymap.lua
• default and user on_attach still look and function the same
• help and all its generation remains unchanged

I reckon this change would only need to hit help.lua and utils.lua for all the desired functionality and would maintain itself.

[alex-courtis]

I'm still keen to get this one in, however it's been inactive for a while.

Please reopen when you'd like to continue @DeH4er