[FEATURE] Build Release Candidate Artifacts on release/* branch, Create/upload/push new tags as new official Odamex Releases, "Push Button Release"

[bcahue]

This is a change that should improve our velocity from the time we feel like an update is ready, to the time that update is deployed and ready to be consumed by the public. I've added 2 new workflows: Windows-Release-Candidate and Windows-Release.

They'll only operate on releases and tags that follow the "major.minor.patch" paradigm (regex verified).

Windows-Release-Candidate only runs on release/ branches, and creates all release candidate build artifacts necessary for a testing group to test the new potential release. The workflow uses gitversion to figure out what the new version should be based off the version name after "release/" in a release branch, like "release/10.3.0". Because I cannot determine RC versions with just gitversion, a new moniker is given as "build_{commits from version source}" to track new release candidates.

A new version of upversion runs here with a Regex to update all old versions and years in the code files. Upversion will then make a commit and merge those changes into the same branch, if there's any changes to be made.

Check here for a workflow run with all artifacts generated: https://github.com/bcahue/odamex/actions/runs/5899187590

Windows-Release is triggered when a GitHub Release is published, and uses the tag given as the version that Odamex should be. Once the release artifacts are generated, they're then uploaded to GitHub Releases to finalize the Release process. This only covers the Windows artifacts, setup exe, and tar.gz and tar.xz files.

The artifacts this does not cover is the MacOS .dmg file which can still be manually uploaded, nor does it make an update to the Odamex website to change the version over to the current one.

Upversion will run here as a convenience but the RC should've been merged back into stable so its unnecessary.

For an example of a completely automated release, check here: https://github.com/bcahue/odamex/releases/tag/10.5.0

Here's the full release process:

1. One makes a new branch (from stable, usually) called release/[major].[minor].[patch] replacing [major].[minor].[patch] with an actual version. This is your RC, except instead of RC numbers you get a build number. The naming here matters as a regex drives this, and non-compliant versions aren't entered into the pipeline. Artifacts are created and should be tested here.

2. As part of this, it automatically upversions to the release you specify as the branch name, and commits this change. This takes care of changing the versions in the launcher, and the copyright year in the code files.

3. When ready to release, merge the release/[major].[minor].[patch] branch into stable and tag it using the same version. Publishing a new release via tag will trigger the 2nd pipeline, which creates all new windows artifacts, installer, and tar.gz/tar.xz/zip files.

Requires testing.

Partially resolves #704