Backport Bot

### Description

Lucene issues stable releases via backporting.

But the backporting is a manual `git cherry-pick` of the committer: maybe they run all tests, maybe some, maybe not.

It would be nice, for the reliability of stable releases, to instead allow the pusher to "label" the PR to indicate a backport. When the PR with such a label is merged, it is backported by a bot: it can e.g. open a backport PR.

With this approach we make it easy, yet also enforce certain safeguards, such as all checks passing.

Currently the PR merges in github are all squash merges, for backporting I think it would cause undue conflicts, change this flow to use ordinary git merge.

Also I'm worried about CHANGES.txt, which is conflict-central, but that can be solved in other ways.

Way down the road:
Maybe we even allow backport to just go in, if all checks pass? or maybe require a different label `trivial-backport` for that. The pusher asked for it. Its just saving time.

No source files or tests are named; start by examining the GitHub PR merge workflow and the existing release/backport process described in the issue. Done would require an agreed design for label-triggered backport PRs, passing-check safeguards, merge strategy, and handling of CHANGES.txt.

Written by the indexing model from the issue text.