go fmt.

go fmt.

result of `gofmt -s -w .`.

result of `gofmt -s -w . `.

According to various blog posts of the official github developer website
[1] [2], the mime preview for Releases and Search are no longer needed.
Moreover, they recommend to use `application/vnd.github.v3+json` for
every requests.

[1] http://developer.github.com/changes/2013-11-04-releases-api-is-official/
[2] http://developer.github.com/changes/2013-10-29-search-api-becomes-an-official-part-of-github-api-v3/

Fix typo in documentation

Includes Repositories.ListReleaseAssets, Repositories.GetReleaseAsset,
Repositories.EditReleaseAsset, Repositories.DeleteReleaseAsset,
Repositories.UploadReleaseAsset.

include Repositories.ListReleases, Repositories.GetRelease,
Repositories.CreateRelease and Repostories.DeleteRelease.

this is a breaking change for a handful of Option structs that were
defining the Page option directly (they now embed ListOptions).

finishes fixing #56

this change also includes some additional minor code cleanup

fixes #58

run through 'gofmt -s'

Fix typo

remove doubly present "the"

this only updates a few user and repo functions just to establish the
calling pattern.  closes #56 (which also includes a little more
background)

ktoso kind of shamed me with his extensive resource tests in #49 :), so
I'm finally starting to setup a structure for more general testing of
this type.  This change adds the `testJSONMarshal` helper function, and
adds tests for the `User` type.  This includes two checks:

 - check that an empty resource produces an empty JSON object.  This
   effectively verifies that all fields include 'omitempty' so that
   we're not unintentionally sending additional data over the wire.

 - check that a full resource with every field populated produces the
   expected JSON.  This verifies that the JSON field mappings are
   correct.  In this case, it might be okay to use resource samples from
   the GitHub docs, though I do still prefer very simple field values
   since it makes tests easier to read.

When these tests are added for each resource type, we can reduce all of
our other tests to return bare minimal response bodies, since the
resource fields are already being tested at that point.

- minor updates to README
- expand package docs to include more information on authentication, as
  well as new sections for rate limiting and setting pointer values.

Add "of" like the rest of the function docstrings

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.