stbt.py: Drop the last sample on underrun

`stbt._display.last_sample` stores the most recent GSt buffer until
`stbt.gst_samples` removes it or it's replaced by a newer buffer.
To put it other way, if the video stream stops then `gst_samples`
yields the very last sample of the video stream even though it's called
minutes later.

This behaviour has unwanted effects in the following situations:

1.
    stbt.press("POWER_OFF")
    time.sleep(5)
    # Make sure that the device under test is off
    try:
        stbt.frames().next()
    except stbt.NoVideo:
        pass
    else:
        raise stbt.UITestFailure("The device is still on")

In this case `stbt.frames` never raises NoVideo, as it yields the
sample that had been stored *before* the box was powered off.

2.
    stbt.wait_for_match("menu.png")
    stbt.press("POWER_OFF")
    time.sleep(5)
    stbt.press("POWER_ON")
    # Make sure that we no longer see menu.png because
    # it should disappear if the device under test is restarted
    try:
        stbt.wait_for_match("menu.png")
    except stbt.MatchTimeout:
        pass
    else:
        raise stbt.UITestFailure("menu.png hasn't disappeared")

In this case we have a race condition between stbt and the device under
test. The device needs some time to start delivering frames after it's
powered on; if it doesn't happen before `gst_samples` is called then
`wait_for_match("menu.png")` returns false positive as the first sample
that `gst_samples` yields is the one that had been stored *before* the
device was powered off.

Note that these issues only occur with Blackmagic and HD PVR capture
devices because VidiUs emit all-blue frames if they don't receive
video.

A solution is to drop `last_sample` if the user data queue sends an
underrun message. However, in my experience capturing video with HD PVR
results in a lot of underrun messages even though the video stream
appears to be continuous. The underrun messages are so frequent that
dropping the last sample after each message results in deleting valuable
video frames and the video output is lagging. To work around this issue,
the same timer is used that "restart source" is using; it's cancelled
if the video stream continues, as signalled by a "running" message.
stbt.py: Stop sink pipeline while the source pipeline is restarting

A VidiU capture device restarts its encoder every time video resolution
changes. It results in an EOS message sent to the source bus
that triggers restarting the source pipeline, as implemented in
6b7ba0a3.

That patch is effective with a simple sink pipeline; however, if the
video saving pipeline is active (--save-video option), tests fail
with one of the following errors:
1. GStreamer raises a general stream error: "streaming task paused,
   reason not-negotiated (-4)".
2. If there are multiple subsequent encoder restarts, the second EOS
   message is not sent, therefore the source pipeline never gets
   restarted for the second time, and the test hangs forever or times
   out with NoVideo.
They are not specific to vp8enc; theoraenc and x264enc also produce
the above errors.

If we stop video encoding when the source pipeline sends the EOS
message, and don't restart it until the source pipeline is successfully
restarted, we can avoid the above failures.

Note that it's not enough to set the sink pipeline to STATE_PAUSED.
When we restart video recording, the video encoder raises the error
"negotiation problem ... encoder not initialized". We have to restart
the encoder in order to successfully resume video recording.

Unfortunately the fix has side-effects:
* As the entire sink pipeline is stopped during source pipeline restart,
  the xvimagesink output window is getting closed for this duration.
  As we don't see any video during a pipeline restart anyway, only a
  black or blue screen, it's not a big deal.
* Every time the video encoder restarts it overwrites the video file.
  A solution is provided in a following commit.

Fixes https://github.com/drothlis/stb-tester/issues/211.
stbt.py: Re-timestamp buffers after source pipeline restart

Every time the source pipeline is rebuilt, timestamps of the video
buffers restart counting from zero. It implies the following issues:
* If the source pipeline is restarted while `gst_samples` is running,
  the actual timeout value is getting unpredictable, as `gst_samples`
  times out if `timestamp - self.start_timestamp > timeout_secs` and
  both `timestamp` and `self.start_timestamp` are reset to 0 while
  `timeout_secs` stays the same.
* Concatenating the video files of a test run produces a corrupted video
  file because the timestamps are not in increasing order. It is also
  impossible to rebuild the video file index (e.g. with `ffmpeg` or
  `avconv`) to make the merged video file seekable.

This commit modifies `on_new_sample` to offset the timestamp of every
buffer by the last video timestamp before the most recent source
pipeline restart, and also by the duration of the pipeline restart
to make `gst_samples` time out at the expected time.

Note that this fix doesn't substitute the patch "Stop sink pipeline
while the source pipeline is restarting". Even though timestamps are
in the right order, without that patch restarting the source pipeline
still results in the same GStreamer error "streaming task paused, reason
not-negotiated (-4)".
stbt.py: Create a new video file each time video recording is restarted

The previous commit modified stbt.py to stop and restart the sink
pipeline every time the source pipeline is rebuilt.

Unfortunately it has an issue that filesink overwrites the video file
every time it gets restarted. A possible solution would be to use the
filesink in "append" mode, but as appending the next video doesn't
modify the video file header, the output file is not seekable.

A working, though slightly inconvenient solution is to save video to a
new file after every filesink restart. Running
    stbt run --save-video video.webm test.py
with a test that involves 2 source pipeline restarts will create
3 files: video.webm, video1.webm and video2.webm.
stbt.py: Save a streamable video and regenerate EBML header at the end

This reverts "Create a new video file each time video recording is
restarted" and replaces with an alternative solution.

Save a single streamable file, i.e. no indexes and duration are written,
and regenerate the header at the end to make the file seekable. As this
solution relies on `ffmpeg` that is only available in `rpmfusion` in
Fedora and Ubuntu is using `avconv` instead, this is just an
experimental commit, not ready for release.