Implemented hook functions

Added support for manipulating webhooks for repositories
Add Stian Eikeland to AUTHORS and CONTRIBUTORS
Restructured Activity Service and Event files.
Restructured Git Data Service files.
Restructured Issues Service files.
Restructured Orgs Service Files.
Restructured Pull Request Service files.
Restructured Repository Service files.
Restructured Users Service files.
Merged webhooks.go into repos_hooks.go
Moved timestamp implementation into its own file.

This was done so that timestamp_test.go would have a corresponding file that
could easily be found. It did not make sense to move timestamp_test.go into
github_test.go if we are trying to move to a more specific source structure.
Various gofmt fixes from restructuring.
Updated CONTRIBUTING.md to describe new naming scheme.
minor cleanup from file refactor

mostly just typos and whitespace
add new Response object which wraps http.Response

This allows use to provide convenience methods for accessing the
paginations links that are returned in HTTP Link headers.  To expose
that, we'll need to return the Response from all API methods, which will
also allow users of the client to do any other kind of inspection of the
response.  This adds additional complexity to the API and will be a
breaking change, but seems to be the cleanest way to enable this sort of
thing.

Refs #22
return Response object from all API functions

The truth is, this change makes me sad.  It's a breaking change
for all clients and it adds more complexity to the library surface.  In
most cases, clients will simply drop the Response object on the floor
(which is actually all the library itself was doing before this
change... now we're just pushing that off to the client).

Initially, the Response object will be primarily of interest for
functions that return paginated result sets, since the Response.NextPage
field is the only way to know for sure if there are more pages that
should be fetched.  And this is really the cleanest way to get at that
data, so in that respect this change isn't so bad.

It's also worth noting that returning the raw Response object makes a
lot more since in a GitHub library than it may in others, given how
GitHub makes liberal (read: proper) use of HTTP request and response
headers.  Other APIs, like Google's various APIs for example, tend to
push things like pagination links into the response body.  While this is
certainly less of a purist view in terms of REST, it does make the lives
of client developers a lot easier, since then the response body contains
everything you need to know.  But whatever; this is how GitHub rolls, so
we'll roll right along with them.  (Somewhat ironically we are ignoring
the RESTful links in the GitHub response bodies, since we're actually
calling the API in an RPC style and don't do anything with those links.)

We still don't have an easy way to set arbitrary request headers, but
that's a problem for another day.

Fixes #22
fix example to handle returned Response