This produces more accurate results and is consistent with similar
code elsewhere.

This change also improves handling of other PullRequestReviewState
values.

The responsibility of marking changes as read is being moved from
the service level to the changes application. This approach scales
better.

It makes it possible to use the changes service for other internal
purposes. For example, it's being used internally as part of
implementing a Gerrit notification v2 service.

It also means the changes application can decide to mark a thread as
read when the user scrolls down and sees the new content, instead of
right away on page load.

In general, it's easier for the changes application to know (with more
certainty) when a change has been read by a user.

Their previous arrangement made it so that the PR review case
completely shadowed the PR review comment case, since
strings.HasPrefix(cr.ID, "r") is always true whenever
strings.HasPrefix(cr.ID, "rc") is true.

Previously, GitHub itself did not support leaving reactions on Pull
Request reviews. It was only possible to leave reactions on normal
comments and inline review comments. They've added that feature now,
so this change implements it accordingly in this package.

Reference: https://developer.github.com/v4/changelog/2019-01-11-schema-changes/.

Reference: https://twitter.com/github/status/1086365048031854592.

This helps with displaying large PRs that have over 100 timeline items
(e.g., https://github.com/neelance/go/pull/7).

The implementation is based the similar issues service ListTimeline,
see https://github.com/shurcooL/issues/commit/4081aa59e957752abbfc6b6fdab72c3bbc1c1dec.

Follows https://github.com/shurcooL/githubv4/commit/19298c78142b5fe80c2cdaa2091bc51cbc3a94fc.

It's not completely read-only now, since it's possible to leave
reactions.

This allows overriding where GitHub PRs can be viewed.

Similar to https://github.com/shurcooL/issues/commit/1cc2d579af3959bb9742445861b47a65a68c1a18.

This is more robust.

It also removes the need to talk to real GitHub API while creating a
new service, which is undesirable during testing.

Analogous to https://github.com/shurcooL/issues/commit/adf13e46e3d966ef14ee08722b56b823cf5c3f3b.

Previously, it panicked. Now that I have a better how to deal with it,
add a comment describing the state. For now, skip such reviews. In the
future, can display them with a pending/draft style.

Page size 100 is largest allowed.

Add full pagination later if/when needed.

It can't be set in Go 1.10 due to reflect changes.

Also switch from githubqlActor to githubqlUser because RequestedReviewer
union is known to be User or Team, so Actor interface is unnecessarily
broad.

References:

-	https://tip.golang.org/doc/go1.10#reflect
-	https://developer.github.com/v4/union/requestedreviewer/
-	https://developer.github.com/v4/interface/actor/

Detect ghost actors/users via them missing entirely, rather than
checking for zero DatabaseID. This is consistent with how GitHub
GraphQL returns them at this time.

Fix minor miscounting issue in reactions method.

Remove unneeded error return parameter from reactions method.

These changes help keep the code more consistent with
issues/githubapi package.

Otherwise, they were showing up as ghost users.

This simplifies things. No need to fetch them out of band.

GitHub notifications for PRs have subject type "PullRequest".