feat: automate the release process via CHANGELOG.md

[galargh]

This PR automates release generation via CHANGELOG.md file.

To create a new release, one has to add a new entry to the CHANGELOG.md file in a Keep a Changelog format.

E.g.

## [1.28.0-rc2] - 2024-06-27

or

## [1.28.0] - 2024-06-27

If no body is provided for that entry (i.e. no non-whitespace characters are found between the h2 version headers), then the release notes will be generated automatically (by the GitHub's release notes generator).

---

Depends on ipdxco/changelog-driven-release#17 ✅ and ipdxco/changelog-driven-release#16 ✅

Automatic notes generation - to be verified how it works in practice here; if it doesn't quite cut it, we'll add manual instructions on how to generate correct notes to the comment that the workflow leaves on the release PR.

[BigLep]

Cool. Thanks for doing this.

My only concerns:

1. We're introducing another way to do releases across this stack (Lotus way, version.go/cargo.toml way, and changelog). I don't think a big deal as each solution makes sense for the repo. More of an observation...
2. Given we're leaning in on the Changelog (fine - cool), it seems odd not to have it getting populated (i.e., we have a file with a bunch of empty headings and I assume that will keep growing because we'll use the GitHub auto-generated text). It would be ideal I think if auto-generated text is created for the release that it also show up in the changelog. (And bonus if the auto-generated text gets updated in CHANGELOG.md that those edits make their way back into the GitHub release.)

[BigLep]

Suggested change

	Create a new entry in the [Changelog](CHANGELOG.md) for the new release. If you don't provide any description/body for the new entry, the release will be created with auto-generated release notes.
	Create a new entry in the [Changelog](CHANGELOG.md) via PR for the new release using the [keep a changelog format](https://keepachangelog.com/en/1.1.0/).
	When the PR is opened, a draft GitHub release will be created.
	When the PR is merged, the GitHub release will be published.
	If you don't provide any description/body for the new CHANGELOG entry, the release will be created with GitHub auto-generated release notes.
	You can read more about this release flow at https://github.com/ipdxco/changelog-driven-release

Might just be me, but this section seemed a little too sparse. I know the process is simple (good), but I think a bit more info is useful.

https://keepachangelog.com/en/1.1.0/ doesn't seem like the right link here given it doesn't specify the ## [x.y.z] yyyy-mm-dd format I don't think. Maybe it would be better to link to https://github.com/ipdxco/changelog-driven-release?tab=readme-ov-file ?

[BigLep]

Can we also have a note about if/how/when release assets are created (since I don't think that is covered in #464 )

[rvagg]

We're introducing another way to do releases across this stack

I was wondering if we had just considered using version.json for this? How was changelog arrived at as the best path for this?

[galargh]

We can use version.json for this. That's no problem at all.

[galargh]

Closing in favour of #475