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`).
Allow user_pipeline to output compressed video

This commit relaxes the requirements of the user provided source pipeline.
Previously it had to provide raw video frames whereas now stbt does
decoding itself.  This is convenient for users but the real advantage is
that it allows us to buffer more intelligently.

raw video takes up lots of memory but it's very easy to manipulate.  You
can drop any frame (`GstBuffer`) and it will have no effect on the meaning
of any previous or subsequent frames.  Compressed video is the opposite.
If you drop buffers in an h264 stream you will see artefacts until the next
I frame comes along.

stbt has some queues set to leaky as our processing can be slower than the
rate at which frames arrive.  It is usually more important that the video
frames being analysed are recent rather than consecutive so we drop frames.
With this commit we are a little more selective and ensure that we only
drop decoded frames rather than compressed ones to avoid artefacts, even
under load.  This makes the assumption that your machine can comfortable
decode video in real time.

This is required to implement smart-tv-support where we wish to operate on
decoded frames but want to avoid dropping any frames that we've done
expensive transformations on - if we have to drop frames under load we
prefer to do it as early as possible in the pipeline to waste the minimum
amount of CPU time.  With this we will be able to insert an additional
transformation pipeline between the leaky queue and stbt's algorithms.

This feature also lays the groundwork for a performance measurement mode
where you don't want to drop any frames as you want to analyse them all,
for instance to measure animation smoothness.  This should now be possible
without having to buffer (potentially GBs of) raw frames in memory.

This is still not perfect.  Ideally in the future we will be able to drop
frames even before decoding them if we can identify that dropping them will
not produce artifacts.  This could be accomplished with a parser (e.g.
h264parse) and flushing the non-leaky queue every time a non-delta frame
is inserted.  But this commit works well enough for now.
Add video transformation pipeline

Commit message TODO
fixup! Allow user_pipeline to output compressed video
fixup! Allow user_pipeline to output compressed video