Fix infinite loop in spurious failure detection

There was a situation where Buffet's detection of spurious failures
could result in an infinite loop.

For the simplest case, consider a spec with 2 examples A and B. If on
the first run only example A fails, Buffet will run the spec again to
confirm the failure. If then on every run thereafter example B fails,
Buffet will continue to rerun the spec indefinitely.

This was caused by the use of the `unconfirmed_failures?` method in
`rerun_spec?`, which would always return a number > 0 for the case
outlined above. This is because example A will always only have failed
once, so it falls within the range of being "unconfirmed" as a failure.

The solution was to add a clause which forces `rerun_spec?` to return
false if the spec has already been run a minimum number of times.

In the process, the failure threshold for spurious failures was upped to
3 so that a quorum is forced in the event of a spurious failure--having
1 failure and 1 success doesn't really tell us that the example is
successful, so we force it to either be 2 failures and 1 success or vice
versa.

Also modified the `Runner` to output the spurious failures even if there
are failures (changing an `elsif` to a separate `if` clause), since we
still want to see the spurious failures.

Change-Id: Ibfb66f52cde5eccc3713dbb8c77f8a8f7980cbd7
Reviewed-on: http://gerrit.causes.com/36923
Tested-by: Shane da Silva <shane@causes.com>
Reviewed-by: Henric Trotzig <henric.trotzig@causes.com>
Reviewed-by: Nebojsa Petrovic <nebs@causes.com>
Cut version 2.0.1

Change-Id: If8f7fdc8f5c515ac68a4cd2a2135565bc29389f9
Reviewed-on: http://gerrit.causes.com/36924
Tested-by: Shane da Silva <shane@causes.com>
Reviewed-by: Henric Trotzig <henric.trotzig@causes.com>
Reviewed-by: Nebojsa Petrovic <nebs@causes.com>