[FR] Add support for backporting PRs “merged” using the `rebase` strategy

@ekohl recently brought up that Patchback gets confused when asked to cherry-pick PRs with several commits that are “merged” using the rebase strategy. My guess is that this is because the API reports one single “merge commit” that is the last commit in the sequence. So our git cherry-pick <committish> invocations would hit conflicts for a series of stacked commits that modify the same code regions.

This is not a problem for true merges and squash-“merges” since both have enough context for cherry-pick to succeed if there's no other conflicts. These operate on a single commit (the true merge needs a -m1 CLI arg, but is the same as squash otherwise).

For rebase-driven “merges”, we need to teach Patchback count the number of the commits in the PR (possible edge-case: merge commits in the PR branch).
Another thing to decide: are the backports expected to squash said series of commits into one, or attempt to preserve the individual ones? Should this be configurable per-repo?

Oh, and how about the fast-forward merges? These don't have a dedicated merge commit and are similar in that they may introduce several new commits in the target branch. I don't think such a merge can be performed from GitHub UI, but it can be done locally, and when pushed, it also marks the PRs as merged, so it'd trigger the same backporting events… We should probably try to detect this edge case too.

Start by tracing Patchback's handling of merged pull-request events and its git cherry-pick invocation. Compare rebase and fast-forward cases, including possible merge commits, and resolve whether backports preserve or squash the commit series and whether that should be configurable. Done means these merge strategies are detected and backported without the described commit-range failures.