Bugs/Problems with the release process

Description

This issue is meant to be part of a larger Epic where we redesign the git flow and release process but it's here to serve as a basis for discussions on how to solve concrete existing problems today.

Bugs are real technical issues that cause inconsistencies, surprising behaviors or simply unwanted outcomes.

Problems are things that are not technically broken but they add complexity and slow the development/release process considerably.

Bugs

• The target Helm repos are not consistently chosen. For example, when a git tag is pushed, the helm-stable is chosen, but when the exact same commit is merged to the main branch, the helm-dev repository is selected. This means that the same release artifacts are pushed to both the helm-dev and the helm-stable repositories.
• Related to the previous one: Any tag that is pushed leads to a release, possibly with an incorrect version (stackabletech/operator-templating#43)
• The operator binaries do not report the Git commit hash at startup anymore. This seems to have been lost while introducing the new GH workflow.

Problems

• The same artifacts are rebuilt/re-published several times.
• The release process is time and people consuming. It takes a full day of work for at least two people.
• There is no coherent "platform-version" maintained.
• The documentation is not versioned (should probably be generated per platform release)

No files, tests, or entry points are named. Start by reviewing the current git tag, main-branch, Helm repository, and GitHub workflow release paths across the affected repositories. Done would require an agreed release-process redesign that addresses the listed bugs and problems.