Includes additions to User, Organization, Repository, and Gist.  Some
minor changes to existing fields based on changes in the v3 API (for
example, Gist.User became Gist.Owner).  Most everything else is new
additions.

refs #103

This includes all of the methods mentioned in this blog post:
https://developer.github.com/changes/2014-03-18-paginating-method-changes/
as well as a handful of others I found.  Sadly, this is a breaking
change for many of these methods because it changes the method
signature, but with yesterday's API change these methods are now broken
anyway. :(

- ListCodeFrequency
- ListPunchCard

- use Timestamp for Week fields instead of int
- rename WeekHash to WeekStats

So it appears GitHub already supports multiple types of subscriptions:
repositories and threads.  I'm leaving the data type simply as
'Subscription', but am updating the method names to avoid confusion,
since they're both part of the ActivitiesService.

mark RateLimit method as deprecated in favor of RateLimits which returns
both the core and search limits. (see deprecation notice in API docs:
https://developer.github.com/v3/rate_limit/#deprecation-notice)

depending on who people are using rate.Reset this may or may not be a
breaking change, since Timestamp supports all of the exported methods
from time.Time.

this is a breaking change, but this was only recently added so I'm not
too worried.  This also seems the best way to handle sub-namespaces on
this method.

- Repositories.Delete
- Repositories.ListTeams
- Repositories.ListTags
- Repositories.GetBranch

I changed my mind.  This really is terribly verbose, and looking at the
design of the API, it seems unlikely GitHub would change the
subscriptions endpoint to include anything other that repositories.  And
if they do...  well, we'll deal with it.

this is a breaking change, but there's no way around that, since the opt
param was left off initially.

(I kinda hate how long some of these names are... I'd much rather just
call them "subscriptions", but the API docs is pretty consistent about
calling them "repository subscriptions", so that's what we go with.
Maybe the intend to later add other kinds of subscriptions?)

User keys can no longer be updated.  Instead, they should be deleted and
re-added.

The GitHub docs don't make it completely clear that AddEmails is also
switching to the new v3 response format, but new integration tests
verify that it is.

This is a breaking change, but it appears that this method has been
broken for some time now and no one has complained yet, so I'm going to
assume no one is using it yet.

Notably, this is also the first (of many, I'm sure) bug I've discovered
while working on the new integration tests (#98).  Yay for better tests!

Signed-off-by: Ondrej Kupka <ondra.cap@gmail.com>

Signed-off-by: Ondrej Kupka <ondra.cap@gmail.com>

notably, this also updates client.Do() to handle non-JSON response
bodies by passing an io.Writer as the final argument, v.

With this code it should be possible to tick the ‘Content’ box in issue
#37. The code is written after reviewing PR #64 and so is (very)
loosely based on that PR. So big thanks for the work already done by
@octavore! I did however had some different insights about a few fixes
and as the PR hasn’t moved for the last 5 months, I thought to just
rewrite and PR and I send in a new PR hoping to come to a merge…

Signed-off-by: Ondrej Kupka <ondra.cap@gmail.com>

This is primarily needed to allow the test to run unmodified in certain
specialized environments (namely, Google's build clusters)

This is a BREAKING CHANGE due to the change in the ListMembers method
signature.

Using an *Issue in IssuesService.{Create,Edit} means that the Labels
and Assignee fields do not serialize to the correct JSON representation
for the GitHub API. This change introduces an IssueRequest struct to
use instead, allowing labels and assignees to be set on create or edit.