stbt.py: Create a new video file each time video recording is restarted

The previous commit modified stbt.py to restart the source pipeline
every time the source pipeline is restarted. It required us to use
filesink in "append" mode to avoid overwriting the video file after each
restart.

Unfortunately the video saved this way is not seekable. A workaround
for this issue is to save video to a new file after every video encoder
restart. The resulting files are all error-free and seekable.

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.

During a VidiU encoder restart the source pipeline gets restarted
multiple times successfully even though we don't receive any data,
resulting in multiple empty video files. Empty video files are
discarded during the following encoder restart.
stbt.py: Drop the last frame on underrun

`stbt._display.last_buffer` 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.

The solution is to drop `last_buffer` 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.
extra/stb-tester.spec: Increment release number