Add pending task capability for opening pull requests

[ChrisMcD1]

• PR Description

Implements #4339.

Creates the new concept of a PendingTask, where gocui is waiting for some action to complete before beginning the real work. In this application, the PendingTask is watching WaitGroup that records that a certain branch is being pushed. Once the branch is finished being pushed, it will automatically start the open pull request command. While waiting on the pending phase of the task, it can be cancelled with the global <escape> keybinding. (I'm not positive where the pending tasks should go in that sequence of cancelling. Perhaps they should be later in that file)

The behavior Demo and ASYNC's Then might also need some more tweaks, I'm not sure about that.

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[stefanhaller]

@ChrisMcD1 I talked to @jesseduffield about this, and we were wondering whether the complexity of this approach is worth it. Also, we are not sure that the proposed UX is the best one.

It might be better (and simpler) to include pushing the branch in the "open PR" command. After all, is there ever a situation where you want to open a PR without pushing your branch first?

The way I think this would work is this: you don't push your branch, but press o or shift-O directly. Then:

1. if your branch has an upstream already, and has a green checkmark, "open PR" proceeds normally as today
2. if the branch has an upstream, but is not up to date, show a confirmation (menu) along the lines of Would you like to (force) push the branch before opening a PR? Yes/No/Cancel. (We'd include "force" only if the branch has diverged.) This would allow for niche use cases like keeping a local "WIP" commit at the top of your branch that you don't want to include in the PR.
3. if the branch doesn't have an upstream yet, show all the necessary prompts for creating one, before showing whatever prompts are needed for opening the PR. Then, proceed to push the branch and open the PR when done; this could be done sequentially from within the same WithWaitingStatus, so much easier to do.

I am very unfamiliar with the shift-O command, and to be honest I can barely tell what all the options in that menu mean; I only use o myself, which doesn't prompt. So I'm not sure how well it would work to show the prompts for pushing the branch and then the prompts for opening the PR, or much work it would be to consolidate them into fewer. For example, asking for which remote to use needs to be done only once for both operations (#4295 is related).

What are your thoughts on this?

[ChrisMcD1]

@stefanhaller Yeah, I can agree with exclusion based on the complexity.

I'll poke around the ideas mentioned to augment the open PR button, they sound quite promising.

On the O vs o note, I myself have also switched back to using o since I learned from you that it worked cross-remote! I used to have jesseduffield's lazygit as my origin, but now I have my fork as the origin. Since my fork's default branch in github for PRs is still this repo, a Po (with the necessary manual waiting time) works fluently to make contributions.