test_that_frames_doesnt_deadlock: Remove harmless but confusing error message

Although this self-test passes, running it with `run-tests.sh -v` showed
the following output:

    test_that_frames_doesnt_deadlock... OK
    Showing '/tmp/stb-tester.roF/log':
    ./test-stbt-py.sh: line 129: frames: command not found
    ./test-stbt-py.sh: line 129: frames: command not found

Since the offending shell command's (lack of) output ended up inside a
Python comment, it didn't affect the correctness of the test; but it was
certainly wrong and confusing.

Thanks to Lewis Haley for spotting this.
Misc: Add make target to generate debian package

This makes it easier to test that the Debian packaging scripts work.
Note: the Ubuntu PPAs and the OpenSUSE Build Service build the source
package directly and won't be using this make target.
Debian packaging: Break up long lines

This makes it easier to read and easier to see changes in a line-by-line
diff.
Port to Gstreamer 1.0

Note: This change will break many user configurations.  See
`docs/backwards-compatibility.md` for migration notes.

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, support for testing Smart TVs with webcams 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

Migration 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 fiddly.

The bigger issue are regressions in upstream GStreamer which affect our
hardware support.  We are fixing issues upstream but this means that you
may have to have a bleeding-edge GStreamer for certain hardware to work.
See `docs/backwards-compatibility.md` for specifics.

Notes:

* For GStreamer 1.0 vp8enc has replaced the property "speed" with
  "cpu-used" where speed=7 is the same as cpu-used=6.  Also the default
  quality settings have changed requiring {min,max}_quantizer to be set.
  See GStreamer BugZilla [#684206] for more information.
* Performance is significantly degraded (by a factor of ~4).  Based on
  profiling this seems to be related to it being slow to create buffers
  from numpy arrays as required for drawing notes on the saved/displayed
  video.  This will be improved in subsequent commits.
* 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 in the
  interests of working with multiple pylint versions the disable remains.
* 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.

[#684206]: 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
Don't skip test_that_video_index_is_written_on_eos on OS X

GStreamer 1.0's webmmux (from macports gstreamer1-gst-plugins-good 1.2.3
package) does work correctly on OS X.
(FAILING TEST) Don't skip test_save_video on OS X

GStreamer 1.0's webmmux does work correctly on OS X (see the previous
commit). However, test_save_video hangs indefinitely. I need to
investigate, but in the meantime I shouldn't hide the problem from
myself (or anyone else testing on OS X). test_save_video does pass on
Linux.
docs/backwards-compatibility.md: Document current hang with Blackmagic
Merge pull request #71 from wmanley/gst-1.0

Port to Gstreamer 1.0
WIP: Allow passing a numpy array as a template to match functions

This allows templates to be generated on-the-fly without having to create
intermediate image files.

TODO:

* Write tests
* Add documentation
stbt tv: Allow complex source pipelines with shell escaping

Previously if you had a stbt.conf like:

    source_pipeline=mysrc property="prop with spaces"

bash would get confused and would pass `property="prop` as `$2` and
separately pass `with` as `$3` and `spaces"` as `$4`.  Using `eval` fixes
this issue although it does make me slightly worried that if some bash
syntax inadvertently ended up in source_pipeline stbt tv could behave
oddly.

This is required for smart-tv support as, due to the complexities of
image processing `source_pipeline`s can require many complex parameters.
debugging: Add checking to gst_to_opencv

OpenCV requires video frames in BGR format.  Previously if you passed a
`GstSample` in another format (e.g. I420 or RGB) `gst_to_opencv` would
either produce a cryptic error message or silently continue having done
the wrong thing.

This commit fixes that by adding an assertion.  Admittedly you have to try
pretty hard to get your hands on a non BGR format `GstSample` but I've
managed it in the past and this would have saved me some debugging effort.
Self-Tests: Improve sandboxing

Take a copy of `stbt.conf` so tests are free to make modifications to it.
Also move `$XDG_CACHE_HOME` into test sandbox dir.  This will be useful
for smart TV support as the calibration and test programs will need to
generate videos for display on the TVs.
Smart TV Support: Add command stbt camera

Entry point for stb-tester support for pointing a camera at a TV.  It is
just a placeholder for now.  Real functionality will be added in later
commits.

Building camera support is optional, as is installing it with rpm as the
RPMs are split into stb-tester and stb-tester-camera.  This will allow
expressing additional dependencies required for camera support but not for
the rest.
Add helper library for generating videos based on stills
Add tv driver
Add fake TV driver for testing
WIP: fake-video-src: Add overlay
WIP: Smart TV support: Add command stbt camera validate

stbt camera validate is intended to measure the quality of video capture
that a camera (plus the software corrections to that camera) provides.  It
does this by displaying images on the TV and then compares the output to
what was expected producing a report.

Currently it defers responsibility for displaying the reference images on
the TV to the user, but support for automatic TV control using DLNA is
coming in the future.

TODO:
* Validate that tests are sufficient?
* Makefile stuff to install validator
* Don't hard-code paths
* Split TV drivers into different python file
WIP: Add video_transformation_pipeline

Turns out that we need more control over the pipeline than we thought.