ci: Create GitHub Release automatically

[leandro-lucarella-frequenz]

Add a GitHub job to create the GitHub Release automatically when a version is tagged. Also use the GitHub feature to create the CHANGELOG automatically. For this the CHANGELOG.md is removed in favor of a RELEASE_NOTES.md files that should only contain an explanation on the release main changes.

Also add the release notes for the current release.

[leandro-lucarella-frequenz]

This PR is also a RFC because it changes the way we build the CHANGELOG. I noticed there is a lot of manual work while GitHub is providing the same automatically for free, so what I'm proposing is to stop wringing a CHANGELOG.md and write a RELEASE_NOTES.md with a more high-level description of what was mainly changed in the release. Here we should include steps needed to migrate from previous versions, examples on new features, etc.

This is how the generated release notes look like:

https://github.com/leandro-lucarella-frequenz/frequenz-api-microgrid-proto/releases/tag/untagged-45de1f171a0afe9f6be2

Everything above What's Changed is the contents of RELEASE_NOTES.md and everything below it was automatically generated by GitHub.

The main advantage is to reduce manual work (we are basically doing the same GH does automatically by listing PRs), the downside is there is no static CHANGELOG (we use the releases page from GH as CHANGELOG).

[leandro-lucarella-frequenz]

ping @tiyash-basu-frequenz @matthias-wende-frequenz @ela-kotulska-frequenz because I'm suggesting a change in the way we do releases and write changelogs / release notes.

[sahas-subramanian-frequenz]

So we create tags locally and push? Or is there a way to create tags on gh without a release?

[leandro-lucarella-frequenz]

So we create tags locally and push? Or is there a way to create tags on gh without a release?

Yeah, I just added the steps to release to the guide. Just tag and push.

[leandro-lucarella-frequenz]

So we create tags locally and push? Or is there a way to create tags on gh without a release?

I didn't thought about creating release+tag via the GH UI but I considered create a release in GitHub and trigger the uploading of the packages to PyPI from that event, but always thinking about pushing a tag first. I found it more complicated, because we should either repeat all the tests for the release event or find a way to wait until the tag is tested to make the release. I thought this workflow was simpler: tag triggers -> create release and upload packages.

If both creating the GH release and the tag are done in the UI I think is simpler, but maybe a bit less resilient if someone wants to create the tag first from the CLI or something.

[tiyash-basu-frequenz]

LGTM!