Further improve how we minimize the possibility of GitHub AbuseException

We seem to be triggering GitHub's abuse detection more frequently as of late and the result is that our automated process raises an issue to add/modify/delete a given yaml file but we don't submit the corresponding PR.

It could be caused by another process running under the `cake-contrib-bot` user and making GitHub API calls around the same time the discoverer is scheduled (need to ask the @cake-contrib/cake-team if any new process is running), or maybe GitHub has changed the heuristics they use to determine if a process is abusing their API. To my knowledge, they don't disclose what these heuristics and therefore not much we can do about it. Either @devlead or @gep13 (it's been a long time, so I don't remember who it was) talked to someone at GitHub about it at some point and they acknowledged that they had heuristics in place, above and beyond the publicly disclosed "rate limits", but they have not disclosed what they are.

That's why I added some defense mechanisms in the discoverer such as:
- don't delete more than 75 yaml files per scheduled run
- don't modify more than 75 yaml files per scheduled run
- don't create more than 75 yaml files per scheduled run
- delay after processing each yaml file. This delay used to be 1 second, it was randomized (between 600 milliseconds and 2 seconds) last month. _Maybe the fact that the delay can now be as low as 600 milliseconds is part of the problem???_
- check the result of Octokit's `.GetLastApiInfo()` and stop processing if there are less than an arbitrary but reasonable (as determined by me) number of calls remaining

But evidently, these are not sufficient, so I propose the following:
- [ ] don't process more than 75 yaml files **TOTAL** per scheduled run (as opposed to 75 delete, 75 modify and 75 create). I don't think this will make a big difference because we rarely delete/modify/add more than 75 files at a time but better safe than sorry.
- [ ] double the random delay (1200 milliseconds to 4 seconds)
- [ ] increase the "minimum number of remaining calls" threshold. Currently 250, maybe increase it to 500???
- [ ] display more info in the log when we trigger `AbuseException`. e.g.: what was the remaining number of API calls prior to the exception, how many yaml file were processed prior to the exception, etc. Maybe this could help us figure out why we are triggering it.

Now that I think about it, I should implement the change to display additional info in the log before changing anything else. Maybe this new information will help me understand the root cause of this problem.