Includes basic CRUD methods on repositories as well as listing branches
and tags.

- 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?)

add tests for User.Edit and User.GetKey

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

This tool help to identify fields being returned by the GitHub API that
are not currently being mapped onto our Go data types.  Some of these
may be deliberate omissions, so these checks should only be treated as
an aid in identifying these fields, not as an absolute list of fields to
be added.

The test public key used in these tests is a key that I just generated
specifically for this purpose.  I deleted the associated private key, so
even if someone accidentally left this attached to their account, it
should have no effect.  Of course, I have no way of actually proving
that I deleted the private key, so uh... yeah.  All the more reason to
never run these integration tests using a "real" GitHub account, always
use a dedicated test account.

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…

Wonder how long those have been there.

The "name" parameter was originally a workaround for the fact that function
pointers in Go never compare equal to each other (unless they are both nil).
Unfortunately, this presents a pretty terrible interface to the end programmer,
since they'll probably end up stuttering something like:

    mux.Use("MyMiddleware", MyMiddleware)

Luckily, I found a workaround for doing function pointer equality (it doesn't
even require "unsafe"!), so we can get rid of the name parameter for good.

This change replaces a bit of API surface area (the Sub() method on Muxes) with
a slightly more expressive pattern syntax. I'm mostly doing this because it
seems cleaner: the "*" gets to take on a meaning very similar to what it means
in Sinatra (without growing regexp-like middle-of-a-path globbing, which sounds
terrifying and not particularly useful), and we get to nuke a useless function
from the API.

These were introduced by breaking changes in the following commits:
- aca58b22cf (ValidMethodsKey)
- 386323a6ed (HTTP methods are case sensitive)