Allow version part to conditionally reset

Reason

This will help some workflows better follow semantic versioning (semver) standards. With a semver of marjor.minor.patch, when also using alpha, beta, and rc parts for releases, there is no supported way to stop a patch bump from getting alpha attached to it. This is a problem as the patch part of a version may not need pre-releases in most cases, we can see this in the Python releases.

There may be a scenario in the workflow stated above where we want to release an alpha version of a patch. Although it would be considered an exceptional scenario, so an exceptional scenario should not be what happens by default.

Problem

# Example setup.cfg
[bumpversion]
current_version = 3.8.4
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(\-(?P<pre>[a-z]+)\.(?P<build>\d+))?
serialize = 
    {major}.{minor}.{patch}-{pre}.{build}
    {major}.{minor}.{patch}

[bumpversion:part:pre]
first_value = alpha
optional_value = gamma
values = 
    alpha
    beta
    rc
    gamma

[bumpversion:part:build]
first_value = 1

My version can now go in 3 possible directions from here, the patch bump cannot be supported in the config.

Bump patch 3.8.4 -> 3.8.5 (not currently possible)
- Actual result is 3.8.5-alpha.1
Bump minor 3.8.4 -> 3.9.0-alpha.1
Bump major 3.8.4 -> 4.0.0-alpha.1

Proposed solution

Adding a reset_with argument that can list the parent parts that the target part will reset with when they are bumped.

# ...
[bumpversion:part:pre]
# ...
reset_with = 
    major
    minor
# ...

Considerations

This solution has a pitfall though. If there is a version of 3.8.5-beta.2, if the patch part is not in the reset_with list, then bumping the patch will go from 3.8.5-beta.2 -> 3.8.6-beta.2. I'm not sure of the cleanest way to avoid this, it seems like more configuration arguments would need to be added to avoid it.

Since this is in the theme of conditionally altering parts of a version based on the bumps of another part, a more scalable solution may be to include a feature that allows completely custom conditional alterations of the version. I would like for this to be explored and discussed since it would be a one-size-fits-all deal. But it seems like a really large feature, and I am not sure how to introduce that idea to the contributors of this project.

Current workarounds

Use the --new_version argument in the command line or in the config file.
- This takes the flow out of workflow since it requires you to do it manually. This also leaves room for human error.
Write a script / alias / bash function / makefile rule etc... to chain bumps of the pre-release part before commiting to git.
- This requires more maintenance of code, it is a liability. If we remove or add a value to the pre-release values list, we now have another batch of code to maintain.
- This also means that you probably cannot have commit = True or tag = True in your config file.

c4urself / bump2version