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.
this function seems like overkill. All it saves you from typing is `exec "git"`. If you wrap this whole file in a function that accepts the `dir` argument you could pre-compute the `options` and simplify your functions below to just call `exec "git ...", options, (error, stdout, stderr)`. This level of indirection doesn't seem to offer any benefit.