Daily cronjob: first iteration

[wilzbach]

Adds a /cron_daily route that can be used to perform polling based PR maintenance.

With this first iteration the bot supports three features:

• detect inactive PRs (Ping or close old PRs with no activity  #47) (via the timestamp of the last activity - atm 90 days without activity are considered as inactive) -> label: "stalled" (I couldn't find a good label for this as inactive PRs aren't tagged atm.)
• detect PRs with merge conflicts (Trigger a warning when a PR gets unmergeable #43) (via mergeable - it's only available in the GH API when the PR is requested directly): -> label: "needs rebase"
• detect PRs with failing CIs (via the status GH API - at the moment the settings is conservative as it requires at the minimum two failed CIs to be detected as such) -> label: "needs work"

The bot just adds or removes labels that match these detected states. With #51 the Dlang-Bot can also automatically remove e.g. the "needs rebase" label on a rebase event.
The main advantage of just using labels to mark "states" of a PR is that it doesn't trigger a notification and also it's a rather safe playground for the first iteration.

Other notes

• While the number of repos isn't limited, for the first iteration I would enable only for Phobos for the the "cron.daily" feature
• I added a stupidly simple authentication mechanism based on the CRON_DAILY_SECRET variable. However as the bot is hosted with SSL-enabled, that should do the trick
• Added a couple of payloads for the new "cron.daily" test (first commit)
• The bot iterated over the IsseList API pages as (1) the updated_at field for PR isn't equivalent to this one (it seems that the PR updated_at gets set by a couple of other things), (2) the IssueList also contains the connected labels and (3) the IssueList is a lot smaller and thus faster to load
• Then as mentioned for every issue its respective pull request details API + status API are called

Other Changes

• Refactored a "PullRequest" to (a) include convenience methods to access its related objects (e.g. commits) and (b) more fields
• Replaced a couple of redundant GH API URLs with their equivalent at the "PullRequest" object
• Added more data objects from the GitHub API
• Needed to add a hack as the maximal stack size of runTask is hard-coded to be 128 bytes
• Removed the restriction that the expecation handlers in the test framework needs be in charge of sending the response. New behavior: If no header has been written:
  (a) and the payload file exists: the fileserver continues to send his reply and the expected payload (allows to set custom response headers)
  (b) and the payload doesn't exist: the request is finished with writeVoidBody (removed a lot of boiler-plate code)

[andralex]

I like this stuff. @MartinNowak? @CyberShadow?

[MartinNowak]

Let's have a look at simply starting a one-shot task in the app with some maintenance parameter from a Heroku Scheduler.