First `wait_for_match` after restarting pipeline obeys `timeout_secs`

The HDPVR video-capture device shuts down completely if the set-top
box's video signal cuts out briefly (e.g. due to HDMI renegotiation on
changing from an SD channel to an HD channel) so we restart the
GStreamer pipeline to get the HDPVR delivering video again.

When the HDPVR starts again, it resets its timestamp back to 0, so the
frames have an *older* timestamp than `start_timestamp` in
`Display.detect`. The effect was a `wait_for_match` with a timeout of
the total time the script has taken to run so far (possibly many
minutes!), plus the given `timeout_secs`.

With other (hypothetical) video-capture hardware that uses wall-time for
its timestamps, this wouldn't be an issue. Even in that case this fix
has the additional effect of resetting the timeout count to start again
after restarting the pipeline; I think that is the correct behaviour
because restarting the pipeline takes up to 10 seconds which is as long,
or longer, than most `wait_for_match` timeouts. Now we give that
`wait_for_match` a real chance to look for a match.