Fix InReplyToID JSON tag for PullRequestComment

[emersonwood]

Fixes #948.

The JSON tag mismatches the one returned from the API, so the value is always encoded as nil.

Relevant docs: https://developer.github.com/v3/pulls/comments/#get-a-single-comment

Also have to use an alias since the JSON tag is different between getting a comment and creating a comment.

I'd be keen to see if there's a more elegant way to do this.

[gmlewis]

I'm looking at the API for CreateComment and I'm not terribly happy with it as it currently stands.

For CreateComment to do its thing, we need just a small subset of the fields provided in the PullRequestComment struct... and there are two variations of the method in the API docs.

What if we were to split the current CreateComment method in two, like this:

func (s *PullRequestsService) CreateComment(ctx context.Context, owner string, repo string, number int, 
comment *PullRequestComment) (*PullRequestComment, *Response, error) { ... }

func (s *PullRequestsService) CreateCommentInReplyTo(ctx context.Context, owner string, repo string, number int, body string, commentID int64) (*PullRequestComment, *Response, error) { ... }

That way, we don't break the current API, but add a simpler method to handle the alternate case?

(I was first going to create a PRCommentRequest struct that had just the fields needed in the first call, but that would break the API and we try not to do that when not absolutely necessary... and I think this case does not require breaking the API... but I think the new helper function to address the alternate call mechanism would be very nice to have and prevent you from having to make an alias.)

[emersonwood]

Thanks for the feedback, I've updated the PR based on your recommendation.

I've updated the original PullRequestComment InReplyTo tag since it's currently incorrect for the GET request, but I haven't changed the field name to avoiding breaking the existing API.

[gmlewis]

Thank you, @emersonwood!
I like this very much!
LGTM.
@juliaferraioli - if you have time to review this, that would be great!
Otherwise, awaiting second LGTM before merging.

TL;DR: The prior version was not populating PullRequestComment.InReplyTo due to a typo in github/pulls_comments.go which this fixes (but we chose not to change the InReplyTo field name as to not break the API... although one could argue that it was already broken and we should change it now to InReplyToID... thoughts, @juliaferraioli?). Also, the alternative way to create a reply comment was not previously supported but now is.

[juliaferraioli]

I agree with @gmlewis that this is the simpler change, and not breaking the API (even with the caveat that it was already broken) makes the most sense.

LGTM!

[gmlewis]

Thank you, @juliaferraioli!
Merging.