In V3 of the GitHub API, pull request comments are created in two ways. The
first way is to create a comment on a specific line of a file in a commit
with the following parameters:

| Name      | Type    | Description                                            |
|-----------|---------|--------------------------------------------------------|
| body      | string  | Required. The text of the comment                      |
| commit_id | string  | Required. The SHA of the commit to comment on.         |
| path      | string  | Required. The relative path of the file to comment on. |
| position  | integer | Required. The line index in the diff to comment on.    |

And the second way is through a reply to an existing comment with the following
parameters:

| Name        | Type    | Description                           |
|-------------|---------|---------------------------------------|
| body        | string  | Required. The text of the comment     |
| in_reply_to | integer | Required. The comment id to reply to. |

This commit adds support for the second (or "Alternative Input" according to
the GitHub docs) way.

Change-Id: I013dcbfb58ec10756c7b4e4bae6fe79b5e7c0062
Fixes #287

This change adds the fields "DiffHunk", "OriginalPosition", and "OriginalCommitId" to the PullRequestComment struct. These fields provide important information about the location of a comment.

Add ListOptions to PullRequestListCommentsOptions and
IssueListCommentsOptions

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

This provides somewhat reasonable string representations of GitHub
structs.  This is specifically designed for this library and takes a
number of shortcuts where it can, so is not suitable as a general
purpose solution.  That said, I am exporting this function because it is
useful for things like printing out slices of GitHub structs, as can be
seen in examples/example.go.

I am certainly open to suggestions for what exactly the stringified
output should look like.  Currently, I think I've found a reasonable
compromise between fmt's "%v" and "%s" output.

Like a51d6b4303, this change makes me sad, mainly because it is a
breaking change for all clients, and makes common tasks like reading
data out of structs slightly more work, with no direct benefit. Notably,
developers will need to make sure and check for nil values before trying
to dereference these pointers.  Sadly, the change is still necessary, as
is more fully explained in issue #19.  We can make the nil pointer
checks a little easier by adding some Get* funcs like goprotobuf does.

I spent a lot of time over the last few weeks exploring this change
(switching fields to pointers) versus the much larger change of using
protocol buffers for all GitHub data types.  While the goprotobuf
library is very mature and feature-rich (it's used heavily inside of
Google), it's the wrong tool for this task, since we're not actually
using the proto wire format.  While it does address the immediate
concern in #19, it makes way too many other things terribly awkward.

One of the biggest drawbacks of this change is that it will make the
string output from fmt.Printf("%v") next to useless, since all pointer
values are displayed as their memory address.  To handle that, I'll be
writing a custom String() function for these structs that is heavily
inspired by goprotobuf and internals from go's fmt package.

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

Since the library has received external contributions, Google is no
longer the sole copyright holder.  Update the boilerplate at the top of
each file to reflect that, and add AUTHORS and CONTRIBUTORS files to
track this information.

This includes most API methods on pull requests (with the exception of
listing commits and the merge functions), as well as all of the methods
for pull request comments. (Fixes #13)

This also fixes a few oversights in the issues API.