Issue webhook payload

[thehowl]

This PR prepares for an upcoming pull request on the main repository that aims to implement go-gitea/gitea#132, adding webhook for issue events.

A small API breakage would be introduced in the SDK (though the API JSON objects' structure would remain untouched, if not for some shifting of the position of the fields). As most fields between the PullRequestPayload and the IssuePayload would be the same, the idea is to move the fields to a common BaseIssuePayload, although this would bring a small breakage to when constructing the struct of a PullRequestPayload:

// No longer possible after this PR
pr := &gitea.PullRequestPayload{
	Index: 64, 
}

However, accessing the struct fields would still be possible after the struct is initialised.

pr := &gitea.PullRequestPayload{}
pr.Index = 64
_ = pr.Index

This would be, however, a very small issue, as the PullRequestPayload is only initialised by Gitea itself (see this github search), but Gitea vendors its dependencies anyway, so this would break only in the event of a vendor update with no update to models/issue.go's struct initialisations.

[lunny]

This line is the only need and put it after the first line.

[lunny]

How about use the duplicated struct between Issue and Pull for the compitable?

[thehowl]

For the computable? I'm sorry, I did not understand. Could you elaborate?

[lunny]

comment

[lunny]

I mean maybe remove BaseIssuePayload and copy the fields to IssuePayload and PullPayload is better.

[thehowl]

Yeah, that was how I originally thought about doing it (and the safest way, since it doesn't cause any breakage). However, it's a matter of convenience and code de-duplication.

I'm gonna do as you said anyway, mostly because of what @tboerger said on Gitter.

[lunny]

LGTM

[thehowl]

I've changed the HookIssueAction names of the ones I added, and removed the comment ones, to better mimic the GitHub webhooks. Issue comments will come at a later stage (and PR).

[tboerger]

LGTM