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().next()` returns false positive, 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_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.

However, if the video saving pipeline is active (--save-video option),
the tests fail with one of the following errors:
1. GStreamer raises a general stream error: "streaming task paused,
   reason not-negotiated (-4)".
2. No EOS message is sent after an encoder restart, therefore the source
   pipeline never gets restarted, and the test hangs forever or times
   out with NoVideo.

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 an error
because video timestamps are getting inconsistent after a source
pipeline restart. We have to restart the encoder in order to
successfully resume video recording.

This fix has a side-effect with xvimagesink. As the entire sink pipeline
is stopped during source pipeline restart, the video output window is
getting closed for this duration. However, as we don't see any video
during a pipeline restart anyway, only a black or blue screen, it's not
a blocking issue.

Fixes https://github.com/drothlis/stb-tester/issues/211.
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 appending the next video doesn't modify
the indexes in the video file header, and therefore the saved video
will not bee 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.

During a VidiU encoder restart the source pipeline may get restarted
multiple times without receiving any data. To avoid having multiple
empty video files, empty files are discarded.
stbt.py: Make decodebin handle asynchronous state changes

While the source pipeline is getting restarted at a VidiU encoder
restart, GStreamer occasionally raises an error in which decodebin
complains that "The stream is of a different type than handled by
this element.: No valid frames found before end of stream".

Setting the "async-handling" parameter of decodebin to "true"
eliminates these errors. As the user-defined source pipeline may also
contain a decodebin element, we have to discover all decodebins and set
the parameter dynamically.
stbt.py: Avoid race condition in restarting source pipeline

`restart_source` doesn't restart the source pipeline immediately after
it's called; it starts a 5-second timer. However, if the source bus
receives another EOS message within 5 seconds (which may happen during
a VidiU encoder restart), it starts a new timer resulting in two
competing restart procedures.

As the first procedure already deleted the source pipeline (set it to
None), the second one raises "AttributeError: 'NoneType' object has no
attribute 'set_state'". This exception is not raised from the main
thread and therefore it doesn't interrupt execution, but it's confusing
to see in the logs.