Add GitHub rate limit monitoring and smart interval estimation

[czechboy0]

We need to be smarter about GitHub's rate limiting, right now we're doing basic math and hoping for the best, but we need a bailout strategy for when we go over the limit and a way to show that in the UI.

[czechboy0]

So rate limiting is described in https://developer.github.com/v3/#rate-limiting. 5000 requests per hour seems reasonable. Also, an interesting way to save requests is to use conditional requests, described in https://developer.github.com/v3/#conditional-requests. Right now, Buildasaur is stateless, it pulls all data again from both Xcode Server and GitHub. Let's look into creating a small local cache so that when we get 304 Unmodified, we can pull the response from it. Also, conditional request cache hit on GitHub doesn't count towards the rate limit, so this might be the way to be able to shorten Builda's turnaround time even further below 15 seconds.

[czechboy0]

I added a basic log for every GitHub response, but that's clogging the log quite a bit. So let's add that information to the GitHub server class itself, it will keep the latest rate limit information, so that the syncer can ask for it when it's preparing the report for the UI (also, the advantage is that the latest response will be taken). Honestly, I can't be bothered to add the local request caching and do all the work to support conditional requests yet, so let's surface the rate limit in the UI and see if anyone actually ends up hitting it in practice.

So two outstanding tasks:

• add latest response's rate limit info to GitHubServer
• add that information to the syncer's report for the UI