Take 2: fix CI release/snapshot race condition

[armanbilge]

Fixes #42.

For context, this is the "race condition" where if a commit is pushed to GH with a tag and CI release is enabled for both tags and snapshots, two publish jobs will start simultaneously and both will have the identical (tagged) version. The workaround is to first push the commit and wait for its (snapshot) publish job to complete, then push the tag separately to trigger the second publish job.

Fixing this problem is also important for projects that may want CI release for snapshots but don't want CI release for tags, such as CE—there needs to be a way for the snapshot publish job to ignore the tags.

The solution here definitely makes me feel a bit queasy: it changes our versioning algorithm depending on the presence/value of an GITHUB_REF_TYPE environment variable, that indicates we are:

1. running in GH actions
2. running in a job that was not triggered by a tag push

When both these conditions are true, the versioning algorithm ignores any "v" tags and adopts a hash version.

One of the nice things about this approach is that we still get one snapshot per push, in addition to any proper release. My previous solution was attempting to disable the snapshot publish job completely.

Thoughts?

[rossabaker]

Is this the first time versioning turns GitHub-specific? That's gross, but I don't yet see a better way.

[armanbilge]

Yep, until now versioning didn't know about GitHub at all. I considered pushing this further down the plugin stack to once of the ci plugins that are GitHub-only. But considering #21 not everyone who does GitHub CI release is using our ci plugin with sbt-gh-actions. So this is the only way to make the fix broadly applicable.