Simplify integration with sbt-release

[julienrf]

There are still a couple of issues to address, IMHO:

• [x] Support escape hatches to manually supply the version number, the compatibility level, or a version qualifier (e.g., -RC1). I introduced a parameter qualifier that can be used to provide an optional version qualifier. I am not sure we should introduce other escape hatches: if someone wants to use a specific version or compatibility intention different from the one that is computed by default, then they would write something like releaseVersion := _ => "1.2.3", or run sbt release with-defaults release-version 1.2.3, or releaseVersion := ReleaseVersion.fromCompatibility(Compatibility.None).
• [x] The current PR makes a strong assumption that the workflow of the user will be the common one where sbt-release manages the version setting in a separate file version.sbt. So it assumes that the version has always been set in a specific manner (patch version has been incremented). I think these assumptions are reasonable.
• [x] Not enough tests in the PR I have amended my commit with more tests and documentation.

[julienrf]

One limitation is that the mode “compute the release version from the level of compatibility with the last release” does not work for the first release. This means you would have to publish a first release in a way, and then update the release workflow to publish the next releases. Ideally, it would be great to define the release workflow once and also handle the first release with it.

[julienrf]

I added a commit that

• resolves the “first release” issue
• reads the release version qualifier from an environment variable VERSION_POLICY_RELEASE_QUALIFIER

I am now happy with the content of the PR, could you please have a look @rtyley?

[rtyley]

Just because they're the maintainer of sbt-release, and this PR might be interesting to them, I'm just going to @-mention @xuwei-k here (apologies, @xuwei-k, if this is not of interest, feel free to ignore!).

This PR is adding support for a new custom versioning strategy that determines the new version number based on sbt-version-policy's assessment of the binary/source compatibility of the new release with the previous release, using the recommended Scala semver rules.

An example of how this might used with sbt-release in a project is in https://github.com/guardian/etag-caching/pull/21, here - it doesn't necessitate either sbt-release or sbt-version-policy having a dependency on each other (because the exposed interface is really just String => String for the version number), though we did copy & paste a small amount of code from sbt-release (Version.scala - both projects are Apache V2) to parse version-numbers and calculate a version string with the appropriate bump.

import sbtversionpolicy.withsbtrelease.ReleaseVersion

...

releaseVersion := {
   ReleaseVersion.fromAggregatedAssessedCompatibilityWithLatestRelease().value
}

We haven't used this code in earnest yet, but should have something usable by sometime next week!