Experiment with milestoned/demilestoned to track backport status

When a PR is attached to an older milestone on backporting, we lose the milestone information because GH only allows to have one milestone per issue.

I have no idea if when the new milestone is set, we get a demilestoned event first (which would be unfortunate as it would make it harder to track the previous milestone for context).

Also from there, we could maybe add a label per branch/a label per version.

Another option could be to NOT affect the milestone when backporting but instead adding a label that would be used when generating the release notes for the release (in conjunction to the milestone).

The number of labels if we use a label per version might become a problem. But maybe we could clean up labels from time to time for old versions (except for the LTS branches).

@maxandersen also mentioned that using projects could be another option to track the versions as you can affect a given PR to multiple projects. The project UI and API might not be as handy though.

Start by investigating GitHub's milestoned and demilestoned events when a pull request's milestone changes during backporting. Compare milestones, version or branch labels, and projects for retaining backport context and release-note generation; done means selecting and documenting a workable tracking approach.