chore: Create automatic release draft action

[marcustyphoon]

Feel free to not bother to review this one, as it obviously will take more of your time to read than it will probably ever save you.

Description

https://xkcd.com/1205/.

Anyway, adapting some work I've done for New XKit and https://github.com/discretize/discretize-gear-optimizer, this creates an action that automatically creates a draft release when the extension manifest version is bumped, with the tag and release notes prefilled.

Along with the existing action, this should make the deploy workflow:

• Commit a bump to manifest.json
• Click the link in the resulting action run or go to https://github.com/AprilSylph/XKit-Rewritten/releases
• Click edit
• Optionally add prose
• Click publish

A less complicated-to-code method—the "normal" way to use https://github.com/softprops/action-gh-release, arguably—would be to fire it when one creates a new tag. A version that did this should make the deploy workflow:

• Commit a bump to manifest.json
• Add a tag to the commit with the corresponding version
• git push --tags or whatever
• Click the link in the resulting action run or go to https://github.com/AprilSylph/XKit-Rewritten/releases
• Click edit
• Optionally add prose
• Click publish

I didn't bother to code this version because the whole point of this PR is to save a couple of seconds, though it would cut the first half of the action, which is kind of nice.

Note: the softprops/action-gh-release action I'm using does have the ability to overwrite a published release with a draft (you may remember I did this on the New XKit repo while testing) and lacks a flag to disable this functionality; test with some caution.

Testing steps

I had to do this on my fork's master branch.

• With a release already existing for the current version, commit a change to manifest.json. Confirm that the action runs, but its second step is skipped and nothing happens.
• Commit a change to manifest.json that bumps the version such that a corresponding release does not exist. Confirm that the action runs and creates a draft release with the correct title and changelog body.

[marcustyphoon]

Note for my future self:

This implements a pattern suitable for a Firefox extension that's listed on the store. The triggering action (bumping the version in manifest.json) runs automation that helps make a github release, and the github release being finalized does the addon store submission. If review then takes a week, users will see the github release but not be able to use it for a week; oh well.

The release automation code I wrote for New XKit implements a pattern suitable for a Firefox extension that's not listed on the store, where the .xpi is downloaded from the github release. The triggering action (dispatching the workflow*) does the addon store submission, then helps make a github release containing the resulting signed .xpi. This requires waiting for review in the action and handling the case where it times out (very messy) but, obviously, you can't make a release containing an .xpi until the .xpi exists.

If one was only publishing to one extension store one could theoretically use the second pattern for the first case to avoid users seeing a release on github that doesn't exist for them, but this risks the opposite problem ("my extension suddenly changed but there's no release information on github") unless a collaborator manually edits and publishes the github release in a timely fashion once they get the review approve email.

*theoretically this could instead be bumping the version in manifest.json, but you don't want to fire this by accident as it "uses up" the version number on the extension store so I would advise against it. in the first case firing the action by accident just makes a release draft without a tag and is thus inconsequential; automate it as much as possible.