Unified Release process

[nblair]

This enhancement intends to unify the release management process. Per @jnweaver in issue #70:

"Doing a full release involves:

• changing the version number in a handful of places, most importantly in bower.json and package.json, but also in a couple places where its referenced in the Jekyll site _layouts/page.html and getting-started/index.md
• tagging the release, e.g. v0.2.3 and pushing the tag
• creating the release build zip file. We're using Grunt here grunt compress:release_zip will add a .zip file to the build directory with the current version (pulled from package.json)
• publishing the release on GitHub (and Nick B publishing it to Maven Central -- we also publish to AWS S3 but we're not using that and you of course wouldn't be able to push there without the keys anyway) and uploading the .zip file you built to the release"

That's too many steps and too many different people.

Some early ideas:

• Have Maven execute the grunt commands. Maven is a feature rich "software project management and comprehension tool", which gives us many tools to automate our build and release management. There are a few different ways we could accomplish this.
• Have Grunt execute the Maven commands. Since this is primarily a front end project, seems sensible to use a tool (grunt) paired closer to front end tooling.

We should try to mock out what the commands would look like with either of these tools.

[jnweaver]

Thanks, Nick. I just addressed the second part of the first bullet point with 826533d -- the Jekyll pages now read the version number from package.json (we wrote a plugin to do this but weren't using it!)

We might also want to look at GitHub's Releases API for issuing the actual GH release and uploading the .zip asset