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.
as a general design principal I'd consider moving the `dir` argument out of every single action function and instead including a single wrapper. It clutters up the workflow in `index` and makes you repeat all sorts of stuff like:

    options =
      dir: dir