Allow sequential backporting fallback strategy

For example, a project has a PR merged into main and needs it ported back into many branches (3.16, 3.15, 3.14, 3.13, 3.12, 3.11, 3.10). This is often a case with infra changes that go into old releases which mainly only get security fixes but also have their infra kept on life support.

The farther we require this to go, the higher the chances of conflicts are. It may be fine to git cherry-pick a thing from that merge into main into 3.16 and 3.15 directly but the rest would need manual intervention which isn't fun. OTOH, if we were to make a backport PR with manual conflict resolution against 3.14, maybe the rest of backports could work from that.

The idea here is that the bot should be able to identify when some backported PRs got merged into LTS branches and re-attempt backporting those more complicated cases from that.

This will probably work better when there's a way of backlinking successful backports to the originally merged PRs and cross-linking the variants of the same patch from the PR body. I wonder if we could somehow also embed in there the cache that Git's rerere feature uses on interactive conflict resolution.

No files, tests, or entry points are named. Start by tracing how the GitHub app identifies and creates backport pull requests, then examine how merged backports could be used as sources for later branches. Done should include a defined sequential fallback strategy for conflicts across the listed LTS branches.