Better support for change groups in our Keep a Changelog parser & writer

Our representation of the [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) format is compliant with the following [Guiding Principles](https://keepachangelog.com/en/1.1.0/#how) from the spec:
- [x] Changelogs are for humans, not machines.
- [x] There should be an entry for every single version.
- [ ] The same types of changes should be grouped.
- [x] Versions and sections should be linkable.
- [x] The latest version comes first.
- [x] The release date of each version is displayed.
- [x] Mention whether you follow [Semantic Versioning](https://semver.org/).

As noted above, we currently do not parse or validate the "change groups" listed in the spec:
- `Added` for new features.
- `Changed` for changes in existing functionality.
- `Deprecated` for soon-to-be removed features.
- `Removed` for now removed features.
- `Fixed` for any bug fixes.
- `Security` in case of vulnerabilities.

Instead, the content between version entries is simply treated as literal text. This is because we have existing changelogs that aren't in compliance with the spec. For example:
- https://github.com/heroku/buildpacks-jvm/blob/main/buildpacks/jvm/CHANGELOG.md
- https://github.com/heroku/buildpacks-nodejs/blob/main/buildpacks/nodejs-corepack/CHANGELOG.md

We also automatically add an default `- No Changes.` entry when a version is bumped as part of our fixed versioning strategy and there are no notable changes from the last version. This does not have an easy representation in the spec.

Questions to discuss:
- How should we deal with those existing non-compliant changelogs?
- How should we track the "No Changes" case?