Cf/460 Create a release workflow to publish new source build artefacts

[traunts]

See #460 for a summary, this will be updated once I've finished drafting it.

This PR introduces changes to the existing build workflows that facilitate automatic versioning and release management of the Source executables. It achieves this through the tool semantic-release, which executes the following steps:

1. Analyse the commit history between the current HEAD ref and the last release (determined by the git tags on the release branch) to determine the new release version, following semantic versioning standards.
2. Generate a set of release notes based on the content of any commits that increment the version
3. Commit a new tag to the release branch (and any changes to version references in the codebase) that labels that ref as a new release version.
4. Publish a new GitHub release containing any build artefacts, source code and the generated release notes.

This workflow is triggered by any push to the master or development branches. Pushes to master will publish a new main release, and label it as the latest official. Pushes to development will publish a prerelease and label it as such.
This allows us to easily distribute dev builds of the source engine while maintaining the official status of the master branch.

This PR includes changes to the current build workflow and adds relevant release config files to enable that.

It also renames and adds a concurrency group to the CI workflow, so new changes to a PR branch will cancel any outdated workflow runs on that PR

Critical Information Summary:

• To determine a version and generate release notes, semantic-release requires that the commits it analyses follow the conventional commits format.

  To bump a version and trigger a new release, at least one commit in a batch of changes must match this format, and be of type fix, feat, or indicate breaking changes with a ! following the type or BREAKING CHANGE: in the commit body.

  Similarly, only commits matching this format will appear in the release notes. When they do they'll be grouped by their type.

  Optimally, all commits that patch the game, add new features or break mods should be formatted like this (as the changes are made) to ensure that all the relevant changes are well captured. Realistically, this is a change to how devs work, and no one likes that, so the absolute minimum requirement is that at least one commit in a batch (For example, the merge commit from a PR) matches the required format.
  This may prove advantageous, as you don't have to worry about junk/testing commits, just formatting the important ones that make changes.

  Note: Failing to meet this requirement won't actually break anything, it just won't bump the version or publish a new release. It may, however, let undocumented breaking changes slip through in later releases.

• Automated versioning requires that the project adheres to the semantic versioning standard, and has published a v1.0.0 release.

  To distinguish between major/minor/patch versions, and importantly, to use semantic-release, the project must either have an existing major version published or start tagging with v1.0.0. semantic-release uses git tags to detect the current version and to judge which commits to include in its analysis when generating a new release version. Without a valid tag containing a semver ${version}, the workflow won't work.

  The workflow will automatically tag and publish prereleases with the format v${version}-pre.${X} on pushes to development, and full releases in the format v${version} on master.

  See https://semantic-release.gitbook.io/semantic-release/support/faq#can-i-set-the-initial-release-version-of-my-package-to-0.0.1
  See the reference fork below for examples. In my case this published a v1.0.0-pre.1 once merged to dev and then a v1.0.0 in master

Other Notes:

• There's a 40-second window in the release workflow's final job where if it's cancelled by another release trigger (concurrency) etc something bad might happen (mid-tag or release etc). IDK I ain't a doctor.
• The release notes generation (in the optimal sense where all changes are well-formatted) can be easily extended to automate the whole changelog generation on release too. See: https://github.com/semantic-release/changelog.
• I wanted to make the release notes prettier/match the existing ones with a brief header, but unfortunately, that functionality isn't available yet. Note that we can still edit the published releases to tidy up any issues, and given core releases from master are infrequent this shouldn't be hard.
  See feat: add option for custom release note header semantic-release/release-notes-generator#349 and feat: add support for title option semantic-release/release-notes-generator#189 which will add this eventually.
• If a tag is generated in a more major branch (master) then the prerelease branches should pull from right after to match that minimum release version (basically merge master back into dev once you merge dev into master)
• This probably requires Add proper semantic version comparison to check mod compatibility #468 and a whole update to the mod converter otherwise we'll have people screaming that mods are bust.

TODO:

• Windows and Linux build jobs should really be turned into reusable actions, as they're duplicated across these workflows. Need to be configurable to work on different build targets (debug/final). I'll openissue™️ for this later, not in scope.
  Make existing build workflows reusable #470
• Might need to narrow the environment variable scope for the GH_TOKEN down to just the release steps, better practice. I'll implement it once this is out of the draft stage.
• Add some more comments to the release workflow clarifying steps (maybe, most are well-named)

Examples of these changes and generated releases can be found here in a testing fork.

Feel free to push to the master/development branches of this forked repo to test how releases are created.

[traunts]

This PR changes the required checks by renaming the workflow and jobs and will require modification of those settings to be able to merge.
Otherwise, it'll flag it as expecting a report from a required check that no longer exists in the head of the PR, so will never run (I've had this issue before, needs Admin oversight)

[traunts]

Deferred until the repo is in a more suitable state to work with this one (monorepo or something, won't work easily without being able to track changes to both projects).