[ENH] include reviewers and committers in contributor list

[minrk]

The most important part of this is done: getting the reviewer list and committer list from graphQL into the data.

• reviews, commits, and comments on merged PRs get counted in the 'all contributors' list

• Instead of only listing the PR author, each merged PR lists contributors to the PR in order:

  1. PR author
  2. all (unique) commit authors and committers
  3. who merged the PR
  4. reviewers
  5. commenters

  In practice, this means most PRs will have at least 2 names associated - the PR author and the merging maintainer.

• reviewers, committers, and commenters show up in the author list for each merged PR

new columns:

• reviews (raw graph)
• reviewers (unique list of reviewers)
• commits (raw graph)
• committers (ordered, non-unique list of committers)

I also moved creation of a couple derivative columns to the end of graphql from generate_activity_md, since that's where most similar code already is, and they were useful earlier in the code than they had been created.

Draft, because there are some open design questions, and I haven't touched any tests:

• [ ] do we separate 'author' (includes committers) from 'reviewers' (probably includes merged-by) in a visible way? If so, is it useful to distinguish merged-by from reviews?
• [ ] Should PR commenters be included; if so, should thresholds be applied, or is one comment sufficient?
• [ ] options - I think including multiple committers in the author list is strictly an improvement over what we have now with just the PR author. But should including reviewers/merger be behind an option, if so on/off by default, etc.? At what granularity (bool for each merger, reviewer, commenter)?

sample output to compare with jupyterhub 2.1.0.

closes #62 closes #67

[choldgraf]

I just want to quickly note that I think this would be a pretty cool and useful functionality to have :-) (see #67)

[minrk]

I know it's been forever, but I've been using this to make the last several JupyterHub release notes, and I like it. I've updated the PR so it passes tests, at least.

I do think it warrants some options to expose to users to make different choices, and I don't know how folks would like to do that.

[choldgraf]

@minrk what do you think about just merging this in + cutting a release, and then iterating on configurability in future PRs? I feel like it is easier to add configurability rather than take it away.

[minrk]

@choldgraf it sounds fine to me, but of course I've entered everything I want as the unconfigurable default, so I have no need of options :)

[choldgraf]

Let's merge and iterate from there!