Bug fix: Ensure that frames are still dropped even after a pipeline restart

If stbt's image analysis is slower than real time frames can get queued
up in the pipeline meaning that the frames we are operating on may be out
of date.  To minimise this latency we drop frames from a queue in the
GStreamer pipeline.

This commit fixes a bug introduced in b8d39d4 where this leaky behaviour
was not being applied after the pipeline was restarted.
stbt.py, stbt-tv: Move the leaky queue right after `decodebin`

This commit resolves high latency of video frames on slow computers by
ensuring that an appropriate number of frames are dropped.

The latency is too high if the same queue is after `videoconvert` even
though the property `leaky=downstream` is set. The idea that the leaky
queue should come before `videoconvert` is the outcome of
trial-and-error.

It is in-keeping with the idea in the pipeline that we shouldn't be
throwing away frames we've done significant processing on.

Note that the slow-down is due to `decodebin` and not stbt's video
processing algorithm. Using `stbt tv` (i.e. a simple video capture
pipeline) without a leaky queue after `decodebin` also results in high
latency.

The "slow computer" used for testing had 2.4 GHz Core 2 Duo CPU.
Merge pull request #151 from szemate/ensure-that-frames-are-dropped

Fix high latency of video frames on slow computers