test_that_video_index_is_written_on_eos is robust under load

When running tests in parallel, this test would occasionally fail with:

    File "webminspector/webminspector.py", line 116, in <module>
      main()
    File "webminspector/webminspector.py", line 97, in main
      pos = segment.SearchLevelOneElements(file_, pos)
    File "webminspector/webm.py", line 560, in SearchLevelOneElements
      size, start_pos = ReadOneByteForElementIdSize(file_, pos)
    File "webminspector/webm.py", line 53, in ReadOneByteForElementIdSize
      file_.seek(pos)
    TypeError: 'NoneType' object cannot be interpreted as an index

Presumably `stbt run` didn't manage to send sufficient data for the
video to be written properly.

This commit re-runs the test with a longer `sleep` if it fails the first
time. I didn't simply increase the timeout because this test doesn't
usually fail when running the tests sequentially (if you don't have GNU
`parallel` installed), so I didn't want to increase the run-time of
a sequential `make check` unnecessarily.
rpm spec file: Add missing dependency "python-flask"

Used by `stbt batch instaweb`.

Note that python-jinja2 is implicitly installed by python-flask, but
I've kept python-jinja2 as an explicit dependency of stb-tester because
stbt.py uses jinja2 outside of flask (to generate the debug html files
from `stbt run -vv`).
tests/test-stbt-batch.sh: Increase timeouts

Self-tests that are testing that `stbt batch run` (without `-1`) keeps
on running until one of the test scripts fails, have a timeout to avoid
the self-test running forever in the (hypothetical) presence of a bug
in `stbt batch run`. This timeout needs to be increased for systems that
are running the self-tests while under heavy load. The increased timeout
shouldn't make any difference to the run-time of these self-tests in the
normal (successful) case.

Thanks to Lewis Haley for reporting the problem:

> I got false negatives for these tests because they were timing out
> before they could conclude. This was probably due to my system having
> a heavy load at the time (running tests with extra logging processes)
> and the stb-tester selftests in parallel.

I also did some related cleanup: I added the `-1` argument to a
self-test that isn't explicitly testing the exit-on-failure behaviour,
but was relying on the fact that `tests/test.py` returns failure the
second time it is run. And I added a timeout to all remaining self-tests
that call `stbt batch run` without `-1`, for consistency.