tests/test-stbt-run.sh: Simplify tests

There's no reason for these tests to run "press" or "wait_for_match" --
all it does is increase the test runtime. And we can use "assert"
directly from python, instead of writing to a log and later grepping
that log.
test_extra_arguments: Test "--" argument to stbt-run

Commit bf393c1d allowed users to pass arguments to the test script on
the stbt-run command line. You can put a "--" between the normal
stbt-run flags and these extra arguments, and the "--" isn't passed on
to the user script. This wasn't documented in bf393c1d, but it's just
the behaviour of python's argparse. This test documents that behaviour,
which is relied on by the next commit.
runner/run: Allow test arguments starting with "-"

Although `stbt run` allows us to specify test arguments, if these start
with a dash, these will be processed as `stbt run` arguments instead of
test ones, i.e.:

    stbt run mytest.py --my-flag

In order to get that working we need to use bash's double dash to force
it to stop taking arguments:

    stbt run mytest.py -- --my-flag

Because of this, when using the runner, it's not possible to do:

    run mytest.py --my-flag

And `run mytest.py -- --my-flag` wouldn't be acceptable because the
double dash is used to separate one test and its arguments from another.
stbt power: Print usage message when no arguments are given

Thanks to Pete Hemery <Peter.Hemery@mathembedded.com> for pointing this
out.
runner report: Replace percentage with confidence interval in summary

As you run more repetitions of a test you get a better idea of how
reliable the test is.  A percentage is useful to describe a failure rate
independent of the number of runs but doesn't include information on how
reliable that percentage is likely to be.

This commit replaces the percentages in the report with percentage ranges
called "confidence intervals".  This means that instead of 43/430 being
a failure rate of 10% it will read 7.5% - 13%.  This means that there is
a 95% chance that the "true" reliability of the test falls between 7.5%
and 13% rather than the potentially misleading 10%.

We use the Wilson Score Interval[1] to calculate the confidence interval.
This assumes a binomial distribution (e.g. test pass/fail results are
independent of each other).

Possible future work:

* Include a further breakdown in the report summary by test exit status
  reason.
* Include a Chi-Squared Test[2] for comparing the results with different
  filters applied to answer questions like "has reliability improved
  between these two versions of software?".
* Write tutorial documentation to help users understand the statistics
  and how to interpret test results.

See also:

* Website for calculating confidence intervals[3]
* Evan Miller's excellent "Statistical Formulas For Programmers"[4]

[1]: http://en.wikipedia.org/wiki/Binomial_proportion_confidence_interval#Wilson_score_interval
[2]: http://www.evanmiller.org/ab-testing/chi-squared.html
[3]: http://vassarstats.net/prop1.html
[4]: http://www.evanmiller.org/statistical-formulas-for-programmers.html
runner report: Minor wording/spelling fixes, wrap lines
Merge branch 'report-confidence-interval'

Closes #76.

* report-confidence-interval:
  runner report: Minor wording/spelling fixes, wrap lines
  runner report: Replace percentage with confidence interval in summary
make check-pylint: Set PYTHONPATH for tests/fake-irnetbox

`fake-irnetbox` worked correctly when run from `run-tests.sh`, because
`run-tests.sh` sets PYTHONPATH correctly; now the `make check-pylint`
recipe also sets PYTHONPATH so that pylint can find the `irnetbox`
module used by `fake-irnetbox`.
extra/stb-tester.spec: Relax pylint < 1.0 requirement

We want people to be able to install the stb-tester RPM on systems like
Fedora 19 that have pylint 1.0. They just won't be able to use the new
`stbt lint` tool (due to bugs with pylint, and possibly differences in
the pylint plugin API; see 97eada33 and 65a38380). Note that `stbt lint`
checks the pylint version and exits with a clear error message.
Bump stb-tester version to 0.17

Note that the version number in the RPM spec file was already set to
0.17 (in 96afe36d; we haven't released the RPM since then so we don't
need to bump the version or release numbers).