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.wait_for_match("blue-screen.png")  # VidiU
    except stbt.NoVideo:  # Blackmagic & HD PVR
        pass
    else:
        raise stbt.UITestFailure("The device is still on")

In this case `wait_for_match` never raises NoVideo, as `stbt.frames`
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