More documentation of pull request processing; release notes

[jtniehof]

This PR adds an initial release notes setup (closes #28), including auto-generated list of closed issues/PRs. That issue contains some example of the output and I suspect we might want to tweak the formatting a bit; it's fairly coarse.

It documents how to mark a PR ready for review (closes #30).

And it documents the Github magic words (closes #29). I think "closes" is probably the preferred word here because "fixes" seems less applicable to e.g. enhancement, but I'm open to objections. I'm also open to saying we don't have a standard, just use a word that does the closing. I also documented using them in both the PR and the commit; I think it helps tie everything together, but open to changing that.

PR Checklist

• [X] Pull request has descriptive title
• [X] Pull request gives overview of changes
• [X] New code has inline comments where necessary
• [X] Any new modules, functions or classes have docstrings consistent with dbprocessing style
• [X] Major new functionality has appropriate Sphinx documentation
• [X] (N/A) Added an entry to CHANGELOG if fixing a major bug or providing a major new feature
• [X] (N/A) New features and bug fixes should have unit tests
• [X] Relevant issues are linked in the description (e.g. See issue # or Closes #)

This PR includes no dbprocessing functionality, but does include code to help prepare the release notes. That's to-standard although it doesn't have tests (it's not particularly testable code.)

[jtniehof]

This doesn't address #40, although it's somewhat relevant, since that will involve both documentation and CI changes; I think that's better left in a separate PR instead of bloating this one more.