stbt.ocr: log text read by Tesseract

It can be nearly impossible to trace errors originating from an OCR
call because up until now the raw text read by Tesseract was not logged
anywhere in output, unless printed explicitly by the caller.
Merge pull request #101 from LewisHaley/log-ocr

stbt.ocr: log text read by Tesseract
stbt batch run: Fix spelling in help message
stbt batch: When run from source dir, use `stbt run` (etc) from source dir

Before this change, running `stbt-batch run` or `stbt-batch report` from
the source directory (for example, when run by the self-tests),
`stbt-batch` would use `stbt run`, `stbt config`, `stbt screenshot` and
`stbt --version` from the *installed* location, not the source
directory.

This meant that the self-tests were testing a combination of the
development version of `stbt batch` with the previous installed version
of `stbt run`. This also made it impossible for me to manually test
changes to `stbt.py` via `stbt batch` without running `make install`.

Note that to run `stbt --version` we use `/bin/sh` because `stbt` isn't
executable in the source directory (because it runs
`$libexecdir/stbt-run` etc so it would be confusing to a user who tried
to run it from the source directory).
Merge remote-tracking branch 'wmanley/set-config'

* wmanley/set-config:
  config: Add `stbt._set_config`
  config: Refactor in preparation for adding set_config

Closes #102.
make check: Fix running from extracted tarball rather than git

Required for Debian packaging support as it by default runs the tests
before building binary packages.
Fix running `make check` when stbt is not installed

Some of the integration tests would fail if stbt was not installed.  This
means that the tests would have been running against (or at least affected
by) the installed version of stbt.  This is bad as the results from `make
check` are then misleading - the installed version may pass but the source
version which you want to check fails.

This commit fixes this issue by taking the sledgehammer approach - do a
`make install` into a sandboxed directory before running the tests.  This
has the beneficial side effect that the integration tests are now also
testing that `make install` works correctly and issues like this are
now unlikely to recur.

This is required for Debian packaging as Debian runs `make check` while
building a package, but is a good idea anyway.
Add support for generating debian packaging

The intention is to set up a Ubuntu PPA to ease deployment onto Ubuntu.

The packages in Debian wheezy (current stable) are unfortunately not
current enough to build and run stbt but it works with Debian testing.
rpm spec file: Fill in Version automatically

With this change the RPM spec file no longer has to be updated with each
release.  Apart from not repeating ourselves this lends itself to more
automation around the release process and the possibility of creating
development RPMs in a continuous fashion using the OpenSUSE Build Service.
rpm: Fix for building rpms for OpenSUSE

OpenSUSE, like Debian but unlike Fedora, expects `libexecdir=/usr/lib`
rather than `/usr/libexec`.  This commit fixes the spec file such that it
can be used to target both OpenSUSE and Fedora.
Add Makefile target obs-publish

Automates pushing stbt updates to the OpenSUSE build service.  The
instructions were going to get a bunch more complicated if we wanted
to add Debian support so this commit automates that process.

This - combined with the change to fill in the rpm spec file version
automatically - also opens the door to the possibility of hooking it into
travis such that we have an stb-tester-master repo so brave souls can run
against git master without having to `make install` themselves.
Merge remote-tracking branch 'wmanley/debian'

* wmanley/debian:
  Add Makefile target obs-publish
  rpm: Fix for building rpms for OpenSUSE
  rpm spec file: Fill in Version automatically
  Add support for generating debian packaging
  Fix running `make check` when stbt is not installed
  make check: Fix running from extracted tarball rather than git
Makefile: Portable implementation of `date -R` for BSD / OS X
Port to Gstreamer 1.0

Gstreamer 1.0 has been out for more than a year now and is where the
majority of the upstream development is going nowadays.  This change will
make it easier to develop further more advanced features such as sound
analysis and new UIs for stbt.

Using GStreamer 1.0 from Python is incompatible with Gstreamer 0.10 in
that Gstreamer 1.0:

1. Gstreamer 1.0 has a different C API to 0.10
2. Some of the elements and properties have been renamed in Gstreamer 1.0.
3. Gstreamer 1.0 uses GObject introspection for automatically generating
   Python bindings from the C API

This was mostly straightforward, but the changes to the appsink/appsrc
were quite tricky.  Because caps information is no longer attached to
buffers appsink now produces `GstSample`s rather than `GstBuffers` which
includes caps information.  Getting this right so the caps can get
through to the appsrc was a little tricky.  Also caps are now set as a
property on appsrc.

Notes:

* For GStreamer 1.0 vp8enc has replaced the property "speed" with
  "cpu-used" where speed=7 is the same as cpu-used=6.  See GStreamer
  BugZilla #684206[1] for more information.
* sink pipeline used in tests now uses xvimagesink.  This needs testing
  on machines which don't have Xv support such as in a VM(?)
* gst_to_opencv now copies the data contained in the array.  It may be
  possible to further optimise this but that will require greater
  understanding on the relationship between Python and GObject lifetimes.
* on_new_sample is called as a GObject callback and should never throw.
  This was noticed as with Gstreamer 1.0 it requires a return value.  We
  should probably catch all exceptions thrown in any callback and work out
  how to signal errors some other way.
* pylint 0.25.1 which I have on my Debian testing machine doesn't
  understand gobject introspection imports so I've had to add a pylint
  disable to the import.  Upgrading to pylint 1.0.0 fixes this but finds
  other issues with the code.  This can be resolved in a seperate commit.
* I've had to increase the default threshold in is_screen_black test as it
  seems, possibly with the move from `video/x-raw-yuv` to
  `video/x-raw,format=I420` that blacks aren't as black anymore, possibly
  as a result of GStreamer 1.0 choosing a different type of yuv in 0.10 or
  possibly due to changes introduced during the ffmpegcolorspace ->
  videoconvert change.

[1]: https://bugzilla.gnome.org/show_bug.cgi?id=684206
debugging: Dump internal GStreamer pipeline state on error

GStreamer has a debug feature where it can dump how a pipeline is wired
up as a graph.  This is very useful for debugging problems with the
GStreamer pipeline.  This commit adds the necessary hooks such that this
information may be dumped when an error occurs much like gst-launch-1.0
already behaves

The effect is that if `GST_DEBUG_DUMP_DOT_DIR` is defined in the
environment and an error occurs a GraphViz dot file will be written to that
directory.  You can then use `dot -T png -o image.png graph.dot` to convert
it to a PNG.

See [Running GStreamer Applications][1] in the GStreamer documentation for
more information.

[1]: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html