stbt.py: Run GLib main loop continuously, and wait on appsink "new-buffer" signals

...instead of polling appsink's "last-buffer" property.

THIS ONLY PROCESSES EVERY SECOND FRAME
======================================

I have 2 threads: One is running the GLib main loop, wich runs the
callback registered against the appsink "new-buffer" signal; this is
labelled "glib***" in the logs below. This merely pushes the buffer
onto a synchronised queue of size 1, dropping old buffers from the
queue. The other thread is running the user's script, e.g.
"wait_for_motion", which pulls the buffer from the synchronised queue (a
blocking "get"). This thread is labelled "user+++" below.

   user+++ Getting buffer at 1370960472.61
   glib*** new buffer (timestamp=0). Queue.qsize: 0
   glib*** new buffer (timestamp=40000000). Queue.qsize: 1
   user+++ Got buffer at 1370960472.72
   user+++ Getting buffer at 1370960472.72
   glib*** new buffer (timestamp=80000000). Queue.qsize: 0
   glib*** new buffer (timestamp=120000000). Queue.qsize: 1
   user+++ Got buffer at 1370960472.79
   user+++ Getting buffer at 1370960472.79
   glib*** new buffer (timestamp=160000000). Queue.qsize: 0
   glib*** new buffer (timestamp=200000000). Queue.qsize: 1
   user+++ Got buffer at 1370960472.91

So it seems the user thread doesn't get scheduled soon enough -- it
doesn't even have a chance to *get* the buffer, before it has been
replaced with the next frame. This halves the maximum frame rate we can
process. I noticed it because the unit test
"test_wait_for_motion_half_motion_int" (which sends video with a
duplicate frame every 2nd frame) failed.
Cleanup: Split tests/test-stbt-run.sh into test-{match,motion,stbt-py}.sh

"test-stbt-run.sh" was getting quite long (650 lines) and the
motion-related tests weren't all grouped together, so it seemed a good
idea to clean this up.
REWORD (add reference to commit removing gst/): Remove tests for GStreamer motiondetect element

And added to "test-motion.sh" tests for functionality that was only
covered in the GStreamer element tests.
REWORD: Fake out "stbt.Display.frames" for flaky tests

These tests test a video stream with "half motion", i.e. where each
second frame is identical to the previous frame (A A B B C C D D etc).
This happens a lot in CCTV footage, in cartoons, etc.

Unfortunately the "videorate" GStreamer element used by these tests
interacts badly with the new appsink-based mechanism introduced in ????.
The thread running the handler for the appsink "new-buffer" signal (this
thread populates "stbt.Display.last_buffer") was getting called in very
quick succession with both of the identical frames, pushing them both
onto "last_buffer" before the user code (in a separate thread) managed
to read from "last_buffer". Halving the effective frame rate just meant
that the "new-buffer" thread processed *four* frames for every frame
processed by the user code, etc.

To make these tests robust, I used a fake "stbt.Display.frames"
function. This avoids GStreamer interactions entirely and focuses on
testing the wait_for_motion "consecutive_frames" handling.
fixup! stbt.py: Run GLib main loop continuously
fixup! REWORD: Fake out "stbt.Display.frames" for flaky tests