feat: When creating a fixup commit on an existing fixup commit, offer to use the base commit

[hhhapz]

When in a workflow where you are applying fixups and using the findBaseCommitForFixup action, a fixup commit (to the intended base commit) instead of the base commit may be selected. In those situations, this PR prompts to target the original commit instead in a modal. This primarily helps in improving commit messages from becoming "fixup! fixup! ".

Three commits are prompted, if a matching base commit is found.

1. The selected commit, if that is the intended behaviour.
2. A base commit in the current todo list of commits (that are pending rebase) using Git's logic for determining the base commits when autosquashing.
3. A base commit using slightly stricter yet more expected rules which is incredibly useful in a workflow when maintaining your own fork.

[Axlefublr]

I asked @hhhapz for this feature! Couldn't be bothered to open an issue ahead of time, but it's a very crucial part of my workflow.

I maintain 10 forks. Lol. Lmao, even.
The most prominent one is my helix fork.
The way I manage it, is that the commits are more like a series of patches I apply on top of upstream.
And so, when I change something in the fork, I usually will fixup! a commit that already exists rather than create a new one.
After I'm done with all my edits in the session, I'll autosquash them with the squashAboveCommits action followed by a “above selected commit” option, when selecting the base commit of my changes.

The default state of the fork is that everything is already merged / pushed. And so, findBaseCommitForFixup will refuse to find me the appropriate commit¹.
So I either have to re-search for the commit again, or make a fixup! fixup! commit. Which quickly gets out of hand and makes the commit message, that I'm fixupping, kind of impossible to see. And is overall clunky!

¹ Which is part of why I forked lazygit too: to allow the action to search through merged commits too.
That's fantastic and all, but at the end of the day the action won't always know what commit I mean. It can't read my mind.
And if I already targeted some commit with a new fixup!, being able to re-target the same commit still comes in incredibly useful.

Fork situations like I have, is a good reason for the “including merged commits” option in the popup. When I want to fixup a commit, I rarely care if it would force a need for a force push, because force pushes is how my forks operate to begin with.