Add missing overloads for list commit comments

[mnivet]

@MitjaBezensek, while writing this last overloads of existing list method (to provide Enumerate and EnumerateAsync overloads) I found that commit and pull requests comments can share the same code.

Doing that I've also tried to change a bit the design used up there to develop resources.

First a rework around the EndPoint class and the way we build Resource classes:

• The new resources I've created extend the EndPoint base class, and have internal constructors
• The EndPoint base class now expose a constructor to build one from a parent (this is to create Resource classes). The goal
• The EndPoint base class is now abstract (this is not a big change since it was clearly already usable only like that) The goal of all that is to avoid to rebuild again and again path strings and call again and again helper methods like GuidOrValue() or ToSlug()

Second usage of more simple method names (just List, Enumerate, Get, Post, Put, Delete). This is because I found that repeating Comment in the name of the methods in addition of the name of the classes and variable feel overkill. And it's on that point were I would like the most a second point of view. I've got the feeling that it could be a good direction to take. but maybe it's to soon. Or maybe it's even something that should never happen in that project, but more in an eventual alternative/fork project where the whole naming style is reviewed. And I'm not sure that a so short naming style is suitable for all endpoints since methods like DeclinePullRequest(...) may be less easy to find with a strict short naming convention...

Thanks for your time if you can give me some advises on that.

[mnivet]

After more investigation it appears that Bitbucket expose two different types: commit_comment and pullrequest_comment one is a comment with a reference on the commit on which the comment is applied, and the second one is a comment with a reference on the pull request. So even if those reference are not fundamental, I finally think that a lib like Sharpbucket should expose the things like they are expose by bitbucket. I will drop that PR and re-do the work with a real separation between the two types of comments. But I'll probably also take the idea of the rework on the EndPoint class