Test: no need to pass assert around

it's already defined for the whole module.
Test: fail a build after starting

Instead of pushing an 'already failed' build through the system,
fail it right before calling finish.
commit-status: only one status when fast-failing

Only report a single "failed" status when a build is "finished" before it is
"started"

Plugins have the option of calling finish() on a build before calling start()
which causes the system to implicitly call start(). The git-build plugin does
this for merge-failures (start isn't usually called till the merge is
successful).

The problem is that "buildStarted" and "buildFinished" are called right after
eachother, causing the github-commit-status plugin to fire off two commit
statuses (one 'started' and one 'merge failed') at almsot exactly the same
time. Github uses whichever status was recieved most recently, so it's kind of
a race condition and half the time, the 'started' message arrives after the
'failed' message, causing a forever 'in progress' state for that commit / pull.

This change simply doesn't send the 'started' status to github during the
'buildStarted' even when a build has already been marked as failed.
Fixtures: Add new conflict-branch

To support a merge-failure test for git-build.js
Tests: add test for merge failure to git-build-test

Need to make sure that merge failures are reported correctly.
Tests: don't unlink git dir symlink afterward

We were getting intermittent failures when the suite was run on
Travis-CI. Turns out they run their builds (on different node versions)
in parallel. Some of the tests modify the filesystem, then clean up
after themselves.

This disables the cleanup, so parallel tests won't screw with
eachother.
Merge git-build-add-merge-failed-test (#40) into master

Tests: add test for merge failure to git-build-test

Need to make sure that merge failures are reported correctly.
Merge github-commit-status-merge-failure-fix (#39) into master

commit-status: only one status when fast-failing

Only report a single "failed" status when a build is "finished" before it is
"started"

Plugins have the option of calling finish() on a build before calling start()
which causes the system to implicitly call start(). The git-build plugin does
this for merge-failures (start isn't usually called till the merge is
successful).

The problem is that "buildStarted" and "buildFinished" are called right after
eachother, causing the github-commit-status plugin to fire off two commit
statuses (one 'started' and one 'merge failed') at almsot exactly the same
time. Github uses whichever status was recieved most recently, so it's kind of
a race condition and half the time, the 'started' message arrives after the
'failed' message, causing a forever 'in progress' state for that commit / pull.

This change simply doesn't send the 'started' status to github during the
'buildStarted' even when a build has already been marked as failed.