initial publish flow

`npub version 1.2.3`

(in order)

- [x] if git status is dirty, abort
- [x] ensure license headers, if requested
- [x] if git status is dirty, abort
- [x] run `npm test` (allow override in config?)
- [x] if exit code is non-zero, abort
- [x] build temp changelog based on commits since last version bump
- [x] open EDITOR with temp changelog
- [x] if exit code is non-zero, abort
- [x] set package version to whatever was specified
- [x] commit changes (changelog and package.json update) with message "v1.2.3" and the changes after a couple of lines
- [x] tag commit as v1.2.3
- [x] confirm "about to publish as version 1.2.3", otherwise abort
- [x] git push [abloom]
- [x] git push $remote tag $tag
- [x] npm publish


---

*broken off into other issues*

- update tag with release notes of this change's changelog
- comment on all PRs associated with this version with a link to the release notes

The config should allow overrides, such as which remote you push to and what verification step to run (instead of `npm test`).

The actual github interactions would be the hardest part. We could do something like https://github.com/kpdecker/git-todo#example to connect to github as the proper user, at least.
it seems really weird to have direct use of `fs` in this file. would it be possible to wrap this logic and the `openEditor` call up inside the `changelog.write` call?

    changelog.write dir, tempChangelog, (path, done) ->
      openEditor path, (err) ->
      done(err)

Where done is defined inside the `changelog` file something like:

    done = (err) ->
      if err?
        fs.unlinkSync path

I'm not sure what the best way to continue to pass the error back up would be, but somehow we'd need to get `endIf(error)` in there.

Just a thought, not a blocker, but something we should clean up in the future,