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.
Hmm, instead of exposing all 3 steps of the `changelog` here maybe it makes more sense to only expose a single `changelog` function that encapsulates all 3 (`build`, `write`, `update`) steps as well as the editor step. That would clean up this file significantly.