feat: added override to prerelease version numbers

[JTeeuwissen]

Fixes: #1793

Modified version of: #1894

The aim of this PR is to allow prerelease version overrides, without resorting to build tags. Which, although supported by SemVer, are not supported by NuGet (which removes the info, causing problems when uploading the same version with different build info).
Overriding this version allows e.g. the pipeline id to be used for increasing versions, even after force pushing to the prerelease branch.

[L3o-pold]

@JTeeuwissen can you show an example of prerelease-version value? I don't get it reading the doc and code.

[JTeeuwissen]

@L3o-pold Sure, Azure Devops names their pipelines like so: #RepoName_CI_2024.02.19.1. Thus, we can use the following value:
${build.replace(/^.*_(\d*).(\d*).(\d*).(\d*)$/, '$1-$2-$3.$4')} to turn the prerelease version into something like this: 2024-02-19.1. With version it could look like: v1.2.3-beta.2024-02-19.1. Which works across force pushes and on NuGet while remaining ordered chronologically. And this allows me to find the pipeline responsible for a release easily.

[L3o-pold]

@JTeeuwissen from where commit and build are populated? ENV var?

[JTeeuwissen]

@L3o-pold envCi is populated using the env-ci package, which is given the env and cwd. But that already was a part of the existing context.

[travi]

closing based on #1793 (comment)

this could potentially be a better fit related to #3046 than related to the existing pre-release workflow. worth noting that we have not yet accepted that request as a type of workflow that we would be willing to support within semantic-release