[dev] Updating the release workflow

[Ralf Lang]

Hello Torben,

I have done some work related to the horde/components release tool while 
commuting.

- Released a new alpha of Cli_Modular with some missing code which was 
already in FRAMEWORK_6 since last year. horde/components now runs. It 
also runs on php 8.4 if you force ignoring platform dependencies.

- Implemented code to properly parse git commit logs and tagging info 
into PHP Objects

First I tried to make git log output json structured info but the 
examples out there all break if you have non-trivial messages containing 
foreign characters, unicode or ' and "
Then I looked into the existing php-git bridge but decided it was too niche.
Then I looked into PHP-FFI accessing libgit2.so but decided it's cool 
and clean to do this, but not my current priority.

- Improved our existing code to handle and manipulate semantic versions 
https://semver.org/
- Implemented ConventionalCommit 
https://www.conventionalcommits.org/en/v1.0.0/

Bottom line: We can simplify our release process and don't need the 
developer to touch composer.json, .horde.yml, changelog.yml or other 
artifacts.

If we write our commit messages the right way, a pull request pipeline 
can "know" if it is a bug fix, feature or breaking commit. On merge, we 
can react to this knowledge, automatically tag and release a version, 
generate the change log and other metadata from git commits etc. The 
main benefit is reducing burden on contributors. In my experience, more 
than two thirds of merge conflicts come from editing the metadata files. 
We can (almost entirely) delegate that to automation.

Tell me if you think this is over the top or otherwise bad.
Else I will finish this change to the tool and start upgrading some 
uncritical libraries' CI pipelines to this new scheme.

Regards


Ralf