Updates project changelog, and any other configured release capabilities.

mix git_ops.release

Logs an error for any commits that were not parseable.

In the case that the prior version was a pre-release and this one is not, the version is only updated via removing the pre-release identifier.

For more information on semantic versioning, including pre release and build identifiers, see the specification here: https://semver.org/

Switches:

* `--initial` - Creates the first changelog, and sets the version to whatever the
  configured mix project's version is.

* `--pre-release` - Sets this release to be a pre release, using the configured
  string as the pre release identifier. This is a manual process, and results in
  an otherwise unchanged version. (Does not change the minor version).
  The version number will only change if a *higher* version number bump is required
  than what was originally changed in the creation of the RC. For instance, if patch
  was changed when creating the pre-release, and no fixes or features were added when
  requesting a new pre-release, then the version will not change. However, if the last
  pre-release had only a patch version bump, but a major change has since been added,
  the version will be changed accordingly.

* `--rc` - Overrides the presence of `--pre-release`, and manages an incrementing
  identifier as the prerelease. This will look like `1.0.0-rc0` `1.0.0-rc1` and so
  forth. See the `--pre-release` flag for information on when the version will change
  for a pre-release. In the case that the version must change, the counter for
  the release candidate counter will be reset as well.

* `--build` - Sets the release build metadata. Build information has no semantic
  meaning to the version itself, and so is simply attached to the end and is to
  be used to describe the build conditions for that release. You might build the
  same version many times, and this can be used to denote that in whatever way
  you choose.

* `--force-patch` - In cases where this task is run, but the version should not
  change, this option will force the patch number to be incremented.

* `--no-major` - Forces major version changes to instead only result in minor version
  changes. This would be a common option for libraries that are still in 0.x.x phases
  where 1.0.0 should only happen at some specified milestones. After that, it is important
  to *not* resist a 2.x.x change just because it doesn't seem like it deserves it.
  Semantic versioning uses this major version change to communicate, and it should not be
  reserved.