Add automated releases to Sonatype Nexus through CI

Overview

Set version in ThisBuild automatically using the output of $ git describe
Add build.sbt configuration for publishing artifacts to Sonatype Nexus
Update to sbt 1.2.8
Update sbt plugin versions and remove unused plugins
Add cipublish STRTA that is branch restricted to master and develop
Add GitHub issue template for releases

Resolves #86

Checklist

[x] Description of PR is in an appropriate section of the CHANGELOG and grouped with similar changes if possible

Notes

We're using sbt-gpg instead of sbt-pgp because the CircleCI build environment is using GnuPG 2.x, and there's no way for sbt-pgp to read a GnuPG 2.x private key.

This came with a few challenges:

sbt-gpg is only targeting Scala 2.12 which necessitated the sbt 1.2.8 bump.
There isn't an easy way to use password protected private keys with sbt-gpg. The recommended approach in their README is to create a dedicated signing key for CI that does not have a password and encrypt it with the Travis CLI tool. CircleCI doesn't support encryption in the same way as Travis, but I figured it'd be safe to base64 the key as a secret environment variable. The difficult part was exporting the signing sub key without a passphrase. I had to use GnuPG 1.4 with the export-reset-subkey-passwd export option.

Also, I have a concern that the cache could possibly grow forever. For example, if we are restoring the old cache, dependencies change, and then we cache the whole ~/.ivy2 directory again, when do the old artifacts ever get cleaned? It's possible sbt is intelligent enough that it is already doing this.

Finally, I am not sure the best approach to resolving the line item:

WIP PR commits can be optionally (via a commit message signal) released as SNAPSHOTS with a Git SHA suffixes; bypass tests flag

It isn't clear cut in the CircleCI configuration how you'd filter based on PR/commit names, etc. This may require additional logic in the STRTA. I think it deserves it's own issue to fully explore.

Testing Instructions

There isn't a way to test automated releases to Maven Central without cutting a real release. I think the best way to do this would be to walk through the release checklist together after merging this PR.

I have tested that if the value of version in ThisBuild does not end with -SNAPSHOT, the publish task will publish artifacts to the staging repository. I discarded the artifacts after doing this. From here, if I had ran sonatypeRelease, the staging repository would sync with Maven Central.

For everything else, see CI checks below.

geotrellis / maml