Add --pre-release option to "force" a prerelease on the current branch if possible

[buehler]

New feature motivation

With the current setup and possibilities for multibranch, maintenance, and prerelease, I messed up several times when merging the different branches together. As such, I merged a breaking change into my release branch that correctly created the new major version. However, the "main" branch - which creates prereleases for each commit - did not update that tag. Now, all further commits created newer versions of the old prerelease.

I thought about a solution for this kind of situation and had one idea: it would be nice to have a flag and/or config possibility that allows me to either have only prerelease branch configs, or trigger prereleases via cli flags.

As an example, I would setup my repository (on GitHub with GitHub Actions) to run a workflow on each commit that lands in "main". When this workflow runs, it adds --pre-release as CLI flag and therefore, depending on the new version, creates a new pre-release.

When I'm satisfied with all the changes currently present for the next release, I run a workflow_dispach (manual) or maybe also a scheduled workflow on GitHub that does not include this flag. This in turn should then result in the next non pre release version being published. As soon as a new commit lands in main, the new version will be a pre-release again.

New feature description

As far as I understand, only two changes are necessary:

1. Allow the branch configuration to have "only prerelease" branches present (when checking the config)
2. Add a cli flag --pre-release that forces the current branch (if configured) to create a pre-release instead of a normal release

With 2. being optional. When using 1., one could use the --branches flag to configure the pre-release on the fly.

In combination with the motivation description, this would result in:

• commit on main branch: semantic-release --branches [{name: "main", prerelease: "whatever"}]
• manual run on main branch: semantic-release or semantic-release --branches ["main"]

New feature implementation

I think only the check about the release branch config is different. Other elements are untouched since the logic remains the same with determining the new versions.