EPIC: Improve release process

[morri-son]

Description
The current release process für the OCM CLI and the GH action(s) invoked, are buggy and way to complex. The aim of this epic is to improve the current process. Going on from the next release 0.17.0 we will ALWAYS create at least one release candidate for every new release. The execution of the integration test suite should be included in the release process as quality gate, failing the release in case it cannot be executed successfully.

The new process should be separated into three main parts:

1.) Prerequisites and actions to be done
2.) Release of a release candidate
3.) Promotion of the release candidate

ad 1.) Instead of creating branches and manipulating the VERSION file as part of GH actions, these two actions are done manually by the engineer that creates the release BEFORE the release process is triggered:

• checkout main branch and pushing it to the new release branch (for y and z releases)
• adopt VERSION file to the release

ad 2.) There should be an idempotent "Release" GH action that can be used to release any kind of release. This action will be triggered on the new branch created and using the information from the VERSION file described in 1.) and creating a release candidate that can be promoted in a subsequent step. The action should include:

• creating single assets for all produced build binaries in all supported platforms
• creating assets for all metadata like signatures, PEM files, SBOM etc.
• creating the CTF that contains all binaries
• using the draft release notes from main release <vx.y.z>, labelling them "pre-release" and with a suffix as <vx.y.z>-<rc.n>
• execute the integration test suite as quality gate and required to run successful for the complete GH action to succeed

ad 3.) There should be a "Promote Release Candidate" GH action that can be used to promote a release candidate to the final release version. The action should include:

• using the RC release, removing the "pre-release" label and setting the "latest" label, making it final
• using all, but the CTF asset, 1:1
• using the CTF from the pre-release to create the final component version with the final release version (custom code required)