Implement "absolute versioning" option

[clong-]

Description

Because github does not guarantee workflow run order in any way, having multiple merges pushed very close together can cause tagging workflows to run out-of-order. If both merges are intended receive a tag, this can result in a scenario where, eg. v1 comes after v2 in history. In this scenario, compute-tag will compute v2 again for the next tag, which will likely cause issues for that workflow, as v2 already exists.

To mitigate this type of race condition, this PR implements what I've come to call "absolute versioning". This scheme counts the number of merge commits between the current commit and the most recent tag in history after the current commit, and then increments the version by that number. This results in state where each tag's value will be some absolute distance from whatever point in history this scheme is implemented, and should always calculate the same version for itself every time it is run.

For example if history looks like (v1) --> ( ) --> ( ) --> ( ), where each ( ) is a merge commit, the rightmost one should calculate v4. If compute-tag is then run for the commit immediately before v4, the computed tag will be v3, since it only looks for tags before it in history when calculating. Thus, we construct a tag history where every tag is at a fixed ("absolute") distance from v1, and guarantee that a unique tag can be calculated for any merge commit, no matter when or in what order the workflow runs.

The caveats of using this scheme are:

• As the calculation is based on merge commits, your repo must be using a merge strategy which generates a merge commit. It will not work properly with fast-forward merge strategies, such as github's rebase-merge and squash-and-merge).
• This scheme assumes continuous versioning.

TODO:

• [] Some documentation for this scheme in README?