Better support for meaningful SemVer-compliant versions

[NthPortal]

Following on from #93, I think it would be valuable to have the option (even if it is not the default) to produce SemVer-compliant versions. Some thoughts on how to do that:

• a dynverStrictSemVer Boolean setting that defaults to false
• for the base version, use the previous version with the patch number incremented by 1
  • since this will only be done if dynverStrictSemVer is set, we can require that the previous version is SemVer compliant
  • stretch goal to have a setting to customise which part of the version gets incremented?
• for the pre-release portion, use dynver.<commits since last release>
  • doesn't have to be dynver, but it would be nice to have some non-numeric string that makes it easy to create other custom pre-releases with higher or lower precedence
• for the metadata portion, use <commit hash prefix>.SNAPSHOT (or something similar that is valid for sonatype/maven)

[NthPortal]

it is not my intention to promote/advertise my own library, but if it would be helpful for implementation, I have a library that parses and manipulates SemVer versions

[dwijnand]

for the pre-release portion, use dynver.<commits since last release>

What was the last release? If you bump the minor or major version you don't know what the last release was.

I'm happy to document in the README how achieving such a version can be configured using sbt-dynver's existing API points, and even make some minor adjustments to those API points to this end. But then I would prefer to wait until it proves its usefulness in the community before folding it into sbt-dynver proper.

[NthPortal]

What was the last release?

whatever the last tag was; i.e. what is currently used as the base version. although I have now realised this isn't a valid default anyway, as it may violate bincompat.

certainly some README tweaks would be greatly appreciated, as I have struggled to figure out how to do this myself