Up until now, a handful of integration tests has been flawed because
we didn't actually verify all nock.js expectations (read: nock.js scope)
had been fulfilled. That was due to a desire to run several methods as
a one-liner instead of one per line;

```
filesScope.done() && existingRepoLabelsScope.done()
```

That could make sense at first glance, but there's a very important
catch we didn't think about when writing it; it requires `.done()`
to return a truthy value or else what comes after `.done()` will not
be executed.

The `.done()` method on nock.js' scope either throws an exception if
the expectation it represents has not been met, or returns
`undefined` when all is good.

That `undefined` value stops the subsequent methods on the same line to
be executed. In other words, we have always just checked the first
expectation, and none of the subsequent ones on the same line.

The changes introduced in this commit executes these `.done()`s on their
own line which sadly causes all of the related tests to explode at
the moment.

Why most of these expectations haven't been met is probably due to
timing issues, since we don't wait for all the related code to have
finished executing before the tests are run. As of now, the code has
been written in a fashion that allows incoming HTTPS requests to be get
their response ASAP, whilst the code pushing PR statuses to github.com
or trigger Jenins builds are still running. That raises some challenges
for our integration tests since they don't really know when the code is
finished, meaning tests can run.

Upcoming changes will fix that by ensuring incoming requests will get
their response *after* all relevant code has succeeded or failed.
That will introduce quite a big refactor job, but the end result will
be a lot more robust tests that can be trusted.