stbt.Display.frames: Always return at least 1 frame

"frames(timeout_secs=0)" would fail with a "Queue.Empty" exception if
called twice in quick succession.

The timeout to "Queue.get" is unrelated to the overall "timeout_secs" of
"frames" (and "detect_match", "detect_motion", etc). The latter are
based on the stream timestamp; the "Queue.get" timeout only has effect
when the GStreamer pipeline isn't delivering any video. There are 2
reasons why there isn't any video:

1. The HDPVR momentarily lost video input, so it switched off. See
   b6135eca. 10 seconds will be enough time to restart the pipeline
   once.

   (Note that we don't want to implement the pipeline restarting
   behaviour here inside "frames" because we want to restart the
   pipeline as soon as video loss is detected, not only when the user's
   script calls "frames". The current implementation listens to
   "underrun" signals from the GStreamer pipeline, in a separate
   thread).

2. The system-under-test isn't delivering video. This might be expected,
   for example if the test script has rebooted the system-under-test. In
   that case your test script would say something like:

       restart_system_under_test()
       wait_for_match('splash_screen.png', timeout_secs=30)

   We want to allow those 30 seconds for video to reappear. In this
   commit's implementation it's possible that we allow a much longer
   timeout:

   * The first 29 seconds of frames *do* have video, but
     "wait_for_match" doesn't find a match.
   * Then in the 30th second we lose video, and we allow an additional
     30s timeout to get the next frame.

   But I don't think that's a big problem. If a test permanently loses
   video it will take a bit longer to fail, that's all.

This commit also gives a "no video" timeout the same behaviour (as seen
by the caller) as a timeout based on the stream timestamps: The
generator returns. Callers like "wait_for_match" can then choose to
raise an Exception like "MatchTimeout".