Improved workflows for CI and releases

[Masgalor]

As discussed here https://github.com/AsherGlick/Burrito/discussions/328 and in accordance with https://github.com/AsherGlick/Burrito/issues/333 this PR fundamentally reworks the workflows used for CI and release-management.

This PR covers every aspect of the meta-issue for this change. I am aware that this is not how it was outlined in the action plan, but I found it difficult to develop this in individual steps. My idea for testing this right now is, to create a fork of AsherGlick/Burrito and merge #342 and this PR into it so every scenario imaginable can be tested. That is what I did during development.

We can split this into some smaller PRs, but since I am working with reusable workflows and actions I see this more as a one or nothing change.

That's it for the intro, lets talk about the details.

---

What is the general concept?

First step is to build the git repository as is job: Pre-Build, this is just to get the checksums of the binaries when they are built from the latest commit. The second step is job: Check, we want to check here if the binaries are different from the last ones, or if we have an untagged commit to create a new release. I know it would be more efficient to check for this before building the reference binaries, but this increases complexity while having no real benefit. If we are sure there are changes warranting a new release we will create a new tag for it. The third step job: Build will build the binaries again, this not important right now as those would not differ from the Pre-Buildones. But this is necessary to use the new tag to set the right version when building the binaries (in the future). The final step job: Publish will create a release and write the checksum for every binary to a git-note at the current tag.

---

What individual parts do we have?

Composite action to analyze our git repository

We need some information from our git data all the time, so we use the custom action `repo-state' to generate an overview for us...

• Last tagged version
• Note on the last tag
• Number of commits since the last tag
• Major version number
• Minor version number
• Revision number

Reusable build-job

The build-process is always exactly the same, otherwise we were not able to compare the checksums of the produced binaries. This job takes care of...

• Downloading and caching the godot installer and templates
• Installing build-dependencies as mingw
• Building everything
• Uploading the built binaries as an artifact
• Creating checksums of everything

Reusable publish-job

If we made it to the publish-stage it is always the same...

• Download the artifacts and package them
• Create a release note
• Create a release
• Write the checksums of the released files to the last tag's note

Create a major release

This is a manually called workflow that creates a major release using the reusable jobs above. It requires a release-note when triggered by hand and can optionally add the commit messages of the relevant commits. This workflow can only be triggered by hand, it will abort if there are no commits without tag or if the binaries are the same as with the last release.

Create a minor release

This is a automatically called workflow that creates a minor release using the reusable jobs above. It is automatically triggered every Tuesday 13h, it does not depend on any inputs, the commit message will be automatically created from the relevant commits. This workflow will abort if there are no commits without tag or if the binaries are the same as with the last release.

Create a bugfix release

This is a manually called workflow that creates a bugfix release using the reusable jobs above. It requires a release-note when triggered by hand and can optionally add the commit messages of the relevant commits. This workflow can only be triggered by hand, it will do anything necessary to make sure a new release is created, no matter if the reference-binaries are the same as with the last release or if there is no commit without a tag. If there is no commit without tag it will create one to make sure there is no commit with two tags at the same time.

---

Notes

We can discuss changes or how to split this in the appropriate issues. I do not like dependencies to random libraries therefore the only external resources are ncipollo/release-action@v1 and simbo/changes-between-tags-action@v1.