Better UX

**Topic**
Lazygit's UX could be improved quite a bit. This discussion is here for the sake of coming up with some UX changes that will make lives easier for Lazygit's users. I mostly want to focus on keybindings. The end-result of this discussion will be a new release of lazygit that revamps the keybindings and gives the users a popup saying 'some things have changed!'.

Suffice it to say that for some of the bigger changes where people have build up muscle memory, we should make it easy enough to revert to the old keybindings (even if that just means pointing them to a doc that gives them a chunk of yaml to chuck in their config).

I have two goals, which sometimes conflict with eachother. I want Lazygit to be easy to use for newcomers, and I want Lazygit to be fast to use for long-term users. I've decided that if we aren't sure whether to add a confirmation panel for something, we should add it. Long-term users will develop the muscle memory to hit 'enter' after the original keybinding so it won't slow them down. We can also allow configuration which removes confirmation panels for things a user might regularly do.

**Your thoughts**

I'm going to phrase this as a proposal but I want to get other people's thoughts before committing. to anything. If you disagree with any of the following, or can think of a better approach, please say so! If you have something similar that you think could be improved, this is a good place to discuss it.

## Left/Right keys
When I first made lazygit, the gocui package depended on termbox which didn't support using shift+tab, so I decided to use the left/right keys to navigate side panels. I've since extended that pattern to other places e.g. the staging panel where left/right flicks you through hunks. Although using left/right is nice in that you don't need to hold down a modifier key, it means we can't use those same keys in contexts where they would make more sense. If we commit to using tab/shift-tab to iterate through things vertically, we can use left/right to introduce vscode-like keybindings for interacting with the file tree, i.e. the left key will collapse the folder, and pressing it again will take you up to the parent folder. Currently we use enter to toggle whether a directory is open and that's not entirely intuitive.

## Global keybindings

No global keybindings should have context-specific overrides. E.g. if 'R' means refresh globally, no panel is allowed to define its own 'R' keybinding (at the moment it will have you reword a commit in the editor without any confirmation panel). Some exceptions can apply if we still provide the option to do the global thing in a menu e.g. pressing 'P' when you've selected a tag should ask you if you want to do a regular 'push' or just push that tag.

## Removing items

Any place we use 'd' to remove an item, we should also be able to use 'backspace' and 'delete'.

## Selecting a range of items

We need a standardised and intuitive way to:
1) select a range
2) select multiple things

Currently in the staging panel you can press 'v' to select a range of lines, and then when you press space it stages those lines. In the commits panel you can press 'c' to pre-select a commit to be cherry-picked, and if you press shift+c it will pre-select from the last pre-selected commit to the current one. Unlike with the staging panel, we have a use case to select multiple things, perhaps with gaps inbetween, ahead of time. At any rate, we should standardise this. I'm not actually sure what makes the most sense, but whatever it is will need to work with the file tree where we'll be using the same pattern for bulk file actions

## Menu-specific keybindings

I often need to hard-reset onto a commit and I don't like having to press 'g' then down twice, then enter. That's four keypresses for something pretty trivial. Reordering those menu items is out of the question given the damage it can do, but what would be great is to be able to specify keybindings for each menu item e.g. 's' for soft reset, 'm' for mixed reset, and 'h' for hard reset. That way I just press 'gh' and I'm done.

An alternative is to do something like vim where you type your keys ahead of time and then something happens, but I am not a big fan of that approach just because I don't find it user-friendly and we can have just as few keypresses taking the menu-based approach that tells users what they're doing as they do it.

## More confirmation panels

Pressing enter doesn't take that long, especially if it's in your muscle memory. We should have a confirmation panel for anything that can get you into a state that's hard to reverse or escape from. This includes the keybinding for rewording a commit in your editor.

Should we include confirmation panels if you've selected an item in a menu? I'm not so sure. That's going to be less accident-prone compared to pressing a random key outside a menu.

## Multiline prompts

The only multi-line prompt right now is the commit message panel. We need to decide on one of the following:
1) enter key always submits, alt-enter (or ctrl-enter) adds newline in multiline prompt
2) enter submits in single-line prompt, alt-enter (or ctrl-enter) submits in multiline prompt (and enter adds a newline)
3) something else

Whichever we go with, we should make it clear to the user which keys do what. Although we currently have the available keys shown in the options view at the bottom of the screen, it's not very obvious. I'd like t see a view sitting underneath the prompt view that tells the user what the important keybindings are.