update release process to support multiple version

[nickfyson]

This PR udpates the release process in order to handle maintaining multiple versions. To a large extent this reintroduces the logic removed in...

• Remove v1 from the release process #1482

...but adapted in order to avoid hardcoding version numbers. The process should also support maintaining two or more older version of the action, should that ever be required.

The process to release a new version will now be to first bump the major version number and merge that PR to main. Then run the update-release-branch.yml workflow, which will...

• create the releases/vNew branch
• open a PR against this new release branch from main
• on merging the release PR...
  • the update-release-branch.yml will be triggered again, this time opening mergeback PRs against from releases/vLatest to all previous supported release branches
  • the update-release-branch.yml workflow will also run, updating the tags for vLatest as required and if the release branch is the latest one then also opening a backport PR to main

Note that both these workflows will also be triggered when mergeback PRs are merged against older release branches, but in this case update-release-branch.yml will take no action and update-release-branch.yml will run only the operations to ensure tags for the relevant version are up to date.

Retiring older versions is now a matter of updating OLDEST_SUPPORTED_MAJOR_VERSION in release-branches.py, see the new section in CONTRIBUTING.md for details.

NB The changes in this PR have been tested in a private fork of the repository.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.
• Confirm the changelog has been updated if necessary.

[henrymercer]

Looks good! My main comment is around what happens the first time we backport a new major version of the Action.

[henrymercer]

Excellent, thanks for addressing my comments!