github: add actions to automate backporting fixes

[kleisauke]

This adds support for automatically cherry-picking fixes for the release branch using a special 'command' in comments:

/cherry-pick <commit1> <commit2> ...

This command attempts to cherry-pick the specified commit(s) to the release branch based on the milestone linked to the issue or pull request. If the commit(s) fail to apply cleanly, then a comment with a link to the failing job will be added to the issue/pull request. If the commit(s) do apply cleanly, the changes will be pushed to a new branch on GitHub, from which a pull request will be created.

Context: #4158 (comment).

[kleisauke]

Example:
kleisauke#5
kleisauke#6

[lovell]

I had a quick look to see if any existing Actions might do something similar, but they all appear to merge/rebase an entire PR rather than allow control over specific commits.

(Introducing the use of milestones would be a good improvement regardless.)

[kleisauke]

FWIW, I just found a small issue in this script, which I reported upstream at llvm/llvm-project#109429.

[kleisauke]

We probably also need to treat release branches as distinct branches after this lands (i.e. the 8.x branches do not need to be merged back into the master branch).

Another point worth discussing is the process for updating changelog notes for patch versions. Should this be done gradually (e.g. as part of the backport or as a separate commit)? Or all at once as part of the patch release?

FWIW, GLib does the latter (see e.g. commit GNOME/glib@bd40fbb). However, these changes do not seem to be reflected in the main branch (see e.g. https://github.com/GNOME/glib/blob/main/NEWS).

[kleisauke]

This is ready for review now. To summarize:

• Release branches are treated as distinct branches after this lands (i.e. the 8.x branches do not need to be merged back into the master branch).
• All non-backport PRs should target the master branch (this also helps new contributors, see e.g. PR Never set the PFM header to little endian #4242).
• Backport PRs should be merged using GitHub's "Rebase and merge" option (to avoid duplicate references and unnecessary Co-authored-by: in commit messages).
• PRs that are likely to be backported (i.e. bug fixes) should not update the ChangeLog directly. The ChangeLog will instead be updated all at once during the patch release (using commit messages as the basis for the entries).

Release branches are still created (i.e "branched") after a minor version is released and before new features are merged into the master branch. We could consider branching earlier (similar to LLVM's approach), but for now, the benefits of doing so appear minimal.

@jcupitt I can help with the releases for the 8.18 cycle (and potentially for any remaining 8.17.x releases) if that would be helpful.

I just found a small issue in this script, which I reported upstream at llvm/llvm-project#109429.

I opened PR llvm/llvm-project#149653 for this upstream. The script in this PR already contains that change.

Should this be done gradually (e.g. as part of the backport or as a separate commit)? Or all at once as part of the patch release?

I think the best approach is to update the ChangeLog notes at once in the patch release, since we need to update the date anyway (see e.g. PR #3663). The only caveat is that the ChangeLog on the master branch lists changes only for minor releases, not patch releases (which is probally fine as most users refer to the release notes at https://github.com/libvips/libvips/releases).