Move publishing to sbt-ci-release, to make releases easier to do

[SethTisue]

Volunteer for this?

RELEASING.md is the current status quo and will need updating along with the build changes.

[SethTisue]

A non-committer wouldn't be able to actually test the changes, as long as the PR looks plausible I would merge it and take care of making any needed final adjustments at release time.

[SethTisue]

RELEASING.md has the current release steps. I went through them manually just now to release 1.1.1 and to make sure I understood everything. Observations:

• We need to be careful that the right matrix entries get published. Would just +publishSigned work as-is, or do we need to make some adjustments? At present the release steps have us doing publishSigned (without the +) to publish the 2.12 stuff including the sbt plugin, then you separately ++2.13 and ++3.2 and run coreJVM/publishSigned and coreNative/publishSigned. We need to be sure that all is handled automatically with sbt-ci-release.
• We need to figure out what to do with testStaging. Currently the release process involves publishing to a staging repo on Sonatype, then using the staged artifacts for a final round of testing before release. We either need to automate that, or allow for it as a manual step. Perhaps the easiest thing would be for sbt-ci-release to only stage the release, and then the test-and-release steps would be manual? Or, perhaps testStaging could be automated to use publishLocaled stuff?

[dwijnand]

I think we can lose it. It was initially a manual step added in 7cfb5e7, but if we can get to a place where it isn't needed then so much the better. Thanks Seth, releases are such a pain for me.