Add repositoryId overloads to methods on I(Observable)RepositoryForksClient

[alexander-efremov]

As part of my work on #1120 I've added new overloads on I(Observable)RepositoryForksClient to get access by repository id.

• Update XML documentation of interface methods of clients (also synchronize XML docs of IRepositoryForksClient and IObservableRepositoryForksClient).

  There is some divergence between XML documentation of methods in IRepositoryForksClient and IObservableRepositoryForksClient. So I've decided
  to sync XML documentation of these classes during my work on Add support for interacting with repositories by id. #1120.

• Add overloads to IRepositoryForksClient.

  Just add overloads of existing methods that use repositoryId to work with repo.

• Add overloads to IObservableRepositoryForksClient.

  Just add overloads of existing methods that use repositoryId to work with repo.

• Add unit tests.

  I've added new unit tests that use repositoryId to work with repo that is just a full copy of existing tests that use (owner, name) key.
  Also I've found out that not all methods are covered by tests and added them for new and for old methods.

• Add integration tests.

  I've added new integration tests that use repositoryId to work with repo that is just a full copy of existing tests that use (owner, name) key.
  Also I've found out that not all methods are covered by tests and added them for new and for old methods.

/cc @shiftkey, @ryangribble

[alexander-efremov]

I've cleared tags here.

[shiftkey]

Ensure.ArgumentNotNull(request, "request")

[alexander-efremov]

done!

[shiftkey]

Tests look good. Just some guard clauses that was previously overlooked and 🔥 the <returns> tags and this is good to go!

[alexander-efremov]

@shiftkey I've add only 2 new guards, but I think it would be a breaking change, because of initial method implementations:

request == null ? ApiConnection.GetAll<Repository>(ApiUrls.RepositoryForks(owner, name), options) : ApiConnection.GetAll<Repository>(ApiUrls.RepositoryForks(owner, name), request.ToParametersDictionary(), options);

What do you think? Should I add null checks?

[shiftkey]

What do you think? Should I add null checks?

I think we should be consistent here with how we accept nulls. We've been favouring throwing when someone passes a null for the request arguments, so I think we should do the same here.

[alexander-efremov]

@shiftkey I agree with you, just I remember that there was other such case in codebase that allow pass null as correct parameter and we left it without additional null checks because of breaking changes (cannot find it right now). Anyway, I'm going to fix this in next 1-2 days 👍

[alexander-efremov]

@shiftkey done!