Ability to set prerelease version suffix separately from branch name

[rconnamacher]

Is your feature request related to a problem? Please describe.

For a project which publishes commits to its main branch as prerelease versions, and would like to use a version matching the pattern 1.0.0-beta.1 or 1.0.0-next.1), it would be nice to configure this. Currently, auto will use the the pattern 1.0.0-main.1.

Describe the solution you'd like

The prereleaseBranches configuration could be updated to adopt a more detailed configuration, like:

{
  "prereleaseBranches": [{"branch": "main", "label": "beta"}]
}

Describe alternatives you've considered

One alternate solution is to rename the branch from main to beta, but that's less clear. In git, "main" (or "master") is typically the branch pull requests get merged to.

A second is to keep 1.0.0-main.1 as the prerelease version for releases produced from the main branch, but that is less clear from a versioning standpoint. "beta" has an established meaning. And for flexibility sake, it would be nice to decouple the two concepts.

A third is to abandon the concept of preproduction releases and give every commit a full production release version. This isn't appropriate for libraries that do produce preproduction versions for testing before blessing something as a full release.

[hydrosquall]

I would find this handy too. Currently I'm working around this in an internal project by getting the default branch renamed from main to next, it helped seeing that this is the convention used by the storybookjs/storybook project (next as the default branch for the repo). However, for repos that have been around for longer and have many integrations which make hard assumptions about the default branch name, this would be a riskier change to make.

[hipstersmoothie]

I like this API addition. Give a bunch of flexibility. I'd be open to merging PRs to help get us there