These tests exercise the code path in all of our API methods where an
error is returned from github.NewRequest().  There are actually only two
ways to trigger an error here:
 - provide a URL which can't be parsed
 - provide a request body which can't be JSON encoded

In theory, it's also possible that http.NewRequest() could return an
error which would make its way up the stack, but in practice this will
never happen.  That's because http.NewRequest(), as currently
implemented, will only ever return an error if it's unable to parse the
provided URL.  But since we're simply passing the output of
URL.String(), we know that it will never be unparseable.  That leaves
the two options above.

For methods that don't have a request body (which is to say, most), all
we can do is force a URL parse error, which is most easily accomplished
by putting an unescaped "%" in the URL path.  This works for methods
that take a string input parameter that is directly added to the path.
If there are no string parameters to the function, or if they're not
part of the URL path, then we're mostly out of luck.  In some of those
cases, we can still try to force a JSON encoding error, but otherwise
there will be no way to exercise this code path in those methods.

Of course in this case, the fact that we can't test the error case means
that the error case isn't actually possible.  Nevertheless, I don't want
to ignore the error entirely in case some future change in the
implementation of github.NewRequest() or http.NewRequest() might
introduce a new possibility for erroring out.

What we're testing here is not likely to be a common error case, and
adding all of these tests to check for it in each method may be a bit
OCD, but I'd rather have the test coverage.