Update release process to maintain both v2 and v1 releases

[henrymercer]

This PR implements a new release process to maintain both v2 and v1 releases of the CodeQL Action, both of which receive updates to the analysis and other features from main.

The new release process is discussed in the updated CONTRIBUTING.md document. We perform the v2 release via a main -> v2 merge, and mergeback v2 -> main as we did before with the v1 branch. However what's new is that we also perform a v2 -> v1 merge to ensure that the v1 branch stays up to date with the latest changes while we need to continue supporting this release.

Please read the backlinked internal issue for information on how this was tested, a link to the design doc, and followup work. Commit-by-commit review recommended.

Handling the v2 -> v1 merge

The most difficult part of this process, and one that is liable to change in the future, is how we handle conflicts between the v2 and v1 branch during the v2 -> v1 merge. For instance, take the state just before the v2 -> v1 merge while we're backporting a new 2.1.7 release to v1:

v2: commits from 2.1.6 --- mergeback patch version bump to 2.1.7 --- new changes to be released in 2.1.7
v1: commits from 2.1.6 --- change version number to 1.1.6

We need to address the conflict between mergeback patch version bump to 2.1.7 and change version number to 1.1.6. However, this is complicated, as the version number appears in three places (package.json, package-lock.json, and node_modules/.package-lock.json) and these files could conflict in other ways (e.g. different package versions between v1 and v2).

Our approach is to create a release prep branch from v1 and revert the "change version number to 1.1.6" commit:

v1-release-prep: commits from 2.1.6 --- change version number to 1.1.6 --- revert "change version number to 1.1.6"

By reverting this commit, the release prep branch will have the 2.1.6 version, which means the "mergeback patch version bump to 2.1.7" commit from v2 can be merged in unproblematically. Once this merge is done, we then update the version number to 1.1.7:

v1-release-prep: commits from 2.1.6 --- change version number to 1.1.6 --- revert "change version number to 1.1.6" --- merge v2 into v1-release-prep --- change version number to 1.1.7

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.