Automatically bump changelog when bumping the version

[wtfiscrq]

Goal:

• Support updating the changelog file (CHANGELOG.md) automatically when running git semver bump.

Why:

• When bumping a project's version (aka releasing) an important part of the process is updating the project's changelog, so that new features/fixes are get documented and communicated to the end-users
• Since git semver is already aware of the commits made between versions, uses good specifications such as Conventional Commits and has knowledge about the project's versions, it's natural for it to support bumping changelogs on top of versions

How:

• Upon bumping a project's version, generate a changelog from the list of commits and append them to the top of the CHANGELOG.md file
• Add a new --skip-changelog flag to git semver bump command so users can skip bumping the changelog (i.e. when they use other solutions to do so or they don't use changelogs at all). Default value is false
• Add a new --changelog-file option to git semver bump command to specify the changelog file. Default value is CHANGELOG.md
• Add a new --changelog-increment-file option to git semver bump command to specify a file to write the increment part of the changelog (the new changes) to. This is particularly useful to use as a description for releases when using platforms like GitHub or Gitlab

Changelog format:

Each increment to the changelog must have the following format:

# <VERSION> (<RELEASE DATE>)

## <CHANGE_TYPE>

- <COMMIT_ID> <COMMIT_MESSAGE>

Notes about the changelog format:

• In the future, we should consider adding all the contributors of a version in the footer of the changelog increment, in every entry or both.

Additional:

• Document the new options and flags

[wtfiscrq]

Since GH is working on new features for GH Releases (github/roadmap#247), I want to re-consider if we want to add this or not. Git SemVer should be focused on helping on projects' versioning, automatically generating changelogs is a nice-to-have feature but not a must-have, specially if other tools support this out-of-the-box.

Git SemVer is not attached to GitHub in anyways and could should still be use usable and helpful for projects using other VCS, so this feature can prove valuable but not as a priority for us as before.

Any opinions @jsmvaldivia?