stbt lint: Better error message when no arguments given
stbt tv: Use osxvideosink on Mac OS X

glimagesink doesn't exist on GStreamer 1.x.
Fix test_ocr_on_live_video failure on OS X

On my Mac OS X system, test_ocr_on_live_video is failing 100% of the
time. The script gets stuck at `stbt.frames(timeout_secs=30).next()`
and times out with a `NoVideo` exception after 90 seconds.

This was already passing on Travis (Ubuntu 12.04).

`git bisect` reveals that this was introduced in c83c42a2, which sets
XDG_CONFIG_HOME (for a good reason) but also sets XDG_CACHE_HOME for
"[future] smart TV support" which hasn't landed yet.

Not setting XDG_CACHE_HOME fixes this problem. Inspecting
`$scratchdir/cache` after the test finished reveals the presence of a
`fontconfig` cache directory -- presumably this has to do with the
`textoverlay` GStreamer element used in the test, and is what causes the
90 second pause. There is also a gstreamer cache directory (containing
the GStreamer registry) but I don't think this takes long to generate
because all the other self-tests complete quickly.

Now that the test passes, it takes 10 seconds to tear down because the
videotestsrc doesn't say "is-live=true" (unlike the majority of
self-tests, which take their source-pipeline from tests/stbt.conf). That
long teardown issue will be fixed in
<https://github.com/drothlis/stb-tester/pull/162>. We'll have to think
about adding some self-tests to make sure that a non-live source works
correctly; until then I'm leaving this test as it is with a non-live
videotestsrc, because this seems to be the only self-test we have that
uses a non-live source.
tests/run-tests.sh: Cleanup: Move error check closer

...to the action that we're checking failed/succeeded. These two lines
got accidentally split up in commit c83c42a2.
Merge pull request #166 from drothlis/osx-fix-test_ocr_on_live_video

Fix test_ocr_on_live_video failure on OS X
stbt.py: Fix Ctrl-C ignored since port to GStreamer 1.0

When the GLib mainloop is constructed through the default Python
constructor it adds a signal watch on SIGINT[1].  This is a python
override[^2] ostensibly to "Retain classic pygobject behaviour of quitting
main loops on SIGINT".  This commit uses the non-override MainLoop
constructor which is more conservative and doesn't add a signal watch.

This change is not without side-effects.  The adding of the signal watch
was causing GLib to create another thread called "gmain".  In my
experiments it seems that our own `_mainloop` wasn't being used (or at
least wasn't necessary) at all.  After this change the "gmain" thread is
no longer created and callbacks are running on our `_mainloop` as expected
from reading the code.

This commit exposes (or at least highlights) that the mainloop code isn't
quite right.  In my tests I get the message "teardown: Source pipeline did
not teardown gracefully" whether I Ctrl-C or not.  This behaviour is,
however, present before this commit, so is not a regression caused by this
commit.

Fixes #138.

[^2]: The new GObject Python bindings are automatically generated from the
      C sources, and so method calls should behave identically to if they
      were made from C.  Overrides are where there is additional code added
      to the bindings for a particular language - in this case Python.

[1]: https://git.gnome.org/browse/pygobject/tree/gi/overrides/GLib.py?id=3.10.1#n513
Tests: Fix typo

The tests actually test SIGTERM not SIGINT.
Display: Fix ungraceful teardowns (with delays) with non-live sources

To shut down the source pipeline it should be sufficient to just call
`source.set_state(Gst.State.NULL)`.  In 52579fad we started attempting a
more graceful shutdown of our source pipeline by sending EOS to it instead.
This was a workaround for buggy BlackMagic GStreamer elements.

Unfortunately this slows teardown down for the cases that don't need
graceful teardown.  For non-live elements which can provide frames at a
high rate there can be sufficient frames in the pipeline to slow teardown
by over 10s in which case stbt considers graceful teardown to have failed.

This commit flushes the pipeline, dropping all buffers currently making
their way from source to our appsink, before sending EOS.  This means EOS
arrives promptly and teardown happens much more quickly.
Refactoring: Tidy up `appsink_await_eos()`

No functional change, just tidier.  I was making modifications in the area
so I thought I'd tidy this up too.
Ctrl-C Fixes: Support Ubuntu 12.04 for Travis

PyGObject <3.7.2 doesn't expose the "new" constructor we'd like to be
using, so fall back to __init__.  This means Ctrl-C is broken on 12.04 and
threading will behave differently on Travis than on our supported systems.

This is a real concern because it means Travis isn't testing the actual
implementation that we are using in production.  Hopefully [Travis will
upgrade][1] soon.  Failing that perhaps other CI systems should be
considered.

[1]: https://github.com/travis-ci/travis-ci/issues/2046