Overhaul Github Actions workflows

[Thodor12]

Made a lot of changes to the current workflow to support better operations.

• Better file structure of the different files, making more use of the reusability aspects
• Added the automatic release triggering features
• Pull request builds no longer use separate workflows for building and prerelease builds, this is included in 1 file (but can be disabled)
• All versioning is no longer based off of tags (which also reduces git checkouts no longer needing tags), instead projects now need to supply a VERSION.txt file (configurable) that holds the current project version.
  • For PR builds, 2 things can happen:
    • If no prereleases need to be made, the version is just the current version already stored
    • If we do want prereleases, versions are always suffixed by [simplified_branch_name]-rc.[buildnum], where [buildnum] will be automatically incremented each consecutive build, because the version number stored in the VERSION.txt will be updated
  • For release builds, this can be a little more dynamic:
    • It's now recommended to provide multiple alternative release workflows in the project, because each release workflow can define whether they want to increment the version, and what kind of release to make.
    • You can create a standard on: push workflow that automatically increments the patch version, who builds a beta release
    • You can create a manual dispatch workflow that increments the major version, but makes no release
    • You can create a workflow that will be triggered by the automatic release scheduler, that will automatically build a release version, but not increment the version at all (GH releases may fail creation if already exist)

!! I'm putting this in early review for feedback, but is not ready until properly tested. !!

[marchermans]

This is not backwards compatible.
As we only have one version on OPC, any change has to at least be backwards compatible.