igor 3.6.0

feat(travis): Refactor and simplify Travis polling (#467)

* chore(travis): Refactor and simplify Travis polling

Previously, the polling, using the Travis v2 API, asked Travis for ~50 repos with recently built builds, and then, _for each repo_, asked for the 5 most recent builds. In other words, each polling cycle hits Travis with ~51 potentially heavy API calls (plus more to fetch logs). This commit brings that number down to 1, using the v3 API, and also removes a lot of code that belongs to the v2 API or was just band-aid for the quirks in the v2 API. One of those quirks was that some builds sometimes disappeared from the API as soon as they were built. I have not been able to verify 100% that this bug is gone in the v3 API, and because this commit removes the band-aid, we should proceed with caution before deploying to production.

* Increase default number of jobs retrieved to 300

* Add a couple of @Deprecated annotations and fix a comment

* Add back the tracking cache due to limitations in the Travis API

Should give us the best of both worlds; no more missed builds and still quite a bit easier on the Travis API. I still need to update tests, will fix ASAP.

* Fix tests

* Add back getJobConfig to TravisService that I erroneously removed in 890bb44

* Add back repo sync and the duration logging

* Add toMillis() to duration logging