Miscellaneous data loading optimizations

[Fs00]

This PR implements several optimizations with the goal of reducing loading times (especially in worst-case scenarios) and reduce data usage when possible:

• for issues and PRs, extract comments from timeline API responses instead of making extra calls to the issue comments API. This change alone does not improve loading times, but reduces the amount of fetched data.
• load branches and tags in parallel when opening the branch selection dialog, instead of sequentially fetching branches first and then tags
• employ a smarter mechanism for finding the number of organization members: instead of fetching the full paginated list of members (which can take a long time for orgs with hundreds of public members), we now only fetch the first page by requesting a single item per page, and then look at the number of total pages in the Link header.
  Since we requested the API to return 1 member per page, the number of pages will be equal to the number of members (except when there are 0 or 1 members in an org, but I made sure to handle that case as well).
• for paginated lists that are fetched entirely by requesting all pages (I looked for usages of ApiHelpers.PageIterator), set the number of results per page to 100 instead of using the default (which is 30).
  This gives a fairly big performance improvement when paginated lists have several hundreds of items. Below are some examples of such worst-case scenarios:

	master	This PR
branches/tags loading (torvalds/linux repo)	7 secs	2,5 secs
PR conversation loading	14 secs	6,5 secs
PR files loading (~2000 items)	22 secs	8 secs
issue conversation loading	16,5 secs	8 secs
PR review loading	22,5 secs	17 secs

It's important to note that performance gains are much less prominent for paginated lists that have less items in total (<100). For example, a PR conversation that previously took 6,5 secs to load now takes ~5 secs in my testing.

One last thing worth mentioning: updating OkHttp to version 4 was required to make AS network inspector work properly, since it doesn't support OkHttp 3.x anymore. Breaking changes in 4.x do not affect us and the bindings were updated to support OkHttp 4 quite some time ago 🙂