Feature Request: allow to specify semver leven of an rc

## What am I trying to achieve?

As part of deployment, I want to create a release candidate that is not necessarily a patch release, for example, going from `1.2.3` to `1.3.0-rc.1`

## What happens right now (observed behavior)

When running `--bump rc` it always is a patch release, so `1.2.3` becomes `1.2.4-rc.1` when releasing then one needs to choose to release it as major, minor or patch as the plain release that just removes the `rc` will only go to patch.

Alternatives (that do not properly work):
- Using set-version --bump minor followed by --bump rc will create a `1.3.1-rc.1`
- Using set-version --bump minor followed by a set version `1.3.0-rc.1` fails since downgrading a version is not allowed

## Why is this a problem

There is no way to move a release from `1.2.3` to `1.3.0` with one or more `rc`s in the process, one either ends with `1.3.1` as a new version, or has release candidates for `1.2.4-rc.*` which would be incorrect in sem-ver terms if changes require a minor release.

## Expected behaviour

A way to increase a RC for both minor and major versions as well so that one can move a release from `1.2.3` to `1.3.0-rc.1` ... `1.3.0-rc.N` to `1.3.0` giving each release the expected and correct semver version.

## Sugested change

Add `minor-rc` and `major-rc` (or alternative namings) to the options for `--bump`; or alternatives I've not thought about

## Work

I'm happy to prepare a PR for the changes if a desired change is agreed on

Start at the CLI handling for the --bump option and trace how release-candidate versions are calculated. Define the accepted major-rc and minor-rc behavior, then verify that versions such as 1.2.3 to 1.3.0-rc.1 and successive RCs reach the expected final release version.

Written by the indexing model from the issue text.