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.get_frame()
    except stbt.NoVideo:
        pass
    else:
        raise stbt.UITestFailure("The device is still on")

In this case `stbt.get_frame` never raises NoVideo, as it returns 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. E.g. if we are running

    `wait_for_match('something.png', timeout_secs=20)`

  and the source pipeline restarts after 10 seconds, it raises
  `MatchTimeout` after ~30 seconds.

* `--save-video` produces a corrupted video file because the timestamps
  are not in increasing order. Even though some players are able to play
  it, it is not possible to rebuild the video index (e.g. with `ffmpeg`
  or `avconv`) to make it 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
results in one of the GStreamer errors "streaming task paused, reason
not-negotiated (-4)" or "negotiation problem ... encoder not
initialized".
stbt.py: Create a new video file each time video recording is restarted

The commit "Stop sink pipeline while the source pipeline is restarting"
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 appending the next video doesn't recreate the video file
header, and therefore the output file would not be 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 streamable video

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.
It's possible to build the video index to make it seekable after the
test is completed with an external application, e.g.

    ffmpeg|avconv -i video.webm -c copy video.seekable.webm