Migrate publishing off of Bintray

[SethTisue]

Because bye-bye Bintray!

However, I don't think it's necessary to do this proactively. It's quite rare that we need to publish a new dbuild version. So we can worry about this if and when the time comes.

Not sure if publishing to Sonatype exclusively is an option, because there's a tarball (.tgz) that needs to be hosted. Perhaps we could publish all the regular JARs to Sonatype, and then work out the tarball hosting with Lightbend IT, using Cloudsmith or, who knows, S3 or whatever.

[SethTisue]

the tarball could probably be served from GitHub

(I'm pondering this again because I think I might need to roll a new dbuild release to take the scala-xml 2.x upgrade)

[SethTisue]

the old instructions are in RELEASING.md

[SethTisue]

I'm going to merge #236 containing work on this, but leave the issue open until I've actually done a release.

At the time I release, I should also look into updating the website — probably just a matter of pushing to the gh-pages branch?

[SethTisue]

the tarball could probably be served from GitHub

for the .tgz hosting, I think I can just do show packageZipTarball and then use the GitHub web UI to attach that .tgz file (e.g. /Users/tisue/dbuild/dist/target/universal/dbuild-0.9.18.tgz) to the release

[SethTisue]

0.9.18 published to Maven Central, but with an .ivy and no .pom — hopefully I fixed it for 0.9.19 in af5406e809221d4ed73c864e4fc1dee10828c3e8

[SethTisue]

I think the publishing is working now