stbt-run: Cleanup: Remove unused import

Unused since 78a50d12.
Cleanup: Only hide argv from the "gst" python module

This makes it clearer that ArgvHider exists to work around a bug in that
specific module. See commit 1bd421b4 for details.
stbt run/record: Hide 'pygobject_register_sinkfunc is deprecated' message

This message was shown every time you ran `stbt run` or `stbt record`.

The `gst` module doesn't use python's `warnings` module; in fact the
message is probably coming from C code because re-assigning python's
sys.stderr to os.devnull doesn't help. For details see this blog post:
http://blog.greghaskins.com/python/1/forcibly-redirect-stdout-stderr-from-extension-modules/

If an exception is thrown from the "import gst" statement (e.g. you
don't have that python library installed) then the exception escapes the
`StdErrHider` context manager, so the exception message *is* printed.
README: Cleanup format of example config file

To my preferred formatting. This shows the reader that indentation is
not necessary, and that spaces are allowed around the "=".
make check-integrationtests: Use ximagesink instead of user's sink_pipeline

On my OS X system, where my user's stbt.conf says to use `glimagesink`,
when I run the tests I get interrupted with a system dialog saying:

    The application "Python" unexpectedly quit while trying to restore
    its windows. Do you want to try to restore its windows again?

Using ximagesink avoids the above problem.

Note that the tests that use `gst-launch` directly (instead of `stbt
run`) *already* use ximagesink (see e.g. tests/test-templatematch.sh)
so this is also more consistent, and there are no users (of these tests)
without X11 to worry about.
stbt.load_defaults: Cleanup: ConfigParser `add_section` isn't necessary

I think it's only necessary for writing config files, not for reading
from them.
stbt-completion: Cleanup: Remove initial "#!bash" line

It isn't actually a valid interpreter directive, because it doesn't have
an absolute path. It *shouldn't* be an interpreter directive because the
script is intended to be sourced into your shell, not run as a
subprocess; but I think it could be confusing to some people because it
looks *almost* like an interpreter directive.

It did serve one purpose: Telling editors like Emacs what type of file
this is, for syntax highlighting etc. The new "-*- shell-script -*-"
has the same effect.
Add copyright & license information to installed files
stbt config: New command-line tool to read a value from stbt config file

If you write your own shell scripts around stb-tester, you can store
settings in the same stbt.conf file that has the stbt settings like
"source_pipeline" and "control", and use `stbt config` to access those
settings.

This will be used by the upcoming tools proposed in
https://groups.google.com/forum/?fromgroups=#!topic/stb-tester/AI8kEmIY-z8

Note that the stbt-completion (bash tab-completion) unit tests run from
`make check-bashcompletion` now have to be run with bash, because they
use bash-specific features like <(process substitution).
New function `stbt.get_config` for stbt scripts to read from stbt.conf

At YouView we have been writing libraries of helper functions, like
"network.disable()" to control the network connectivity of our
system-under-test. So far we have been using environment variables to
let those libraries know, for example, the network interface of the
system-under-test, so that we can run the same stbt script and the same
library, without modification, against multiple different set-top boxes.

So we've ended up with some information in stbt.conf (e.g.
source-pipeline, which is different for each system-under-test because
the "/dev/videoN" device is different) and some information in
environment variables.

Thanks to this new `stbt.get_config` function we can store all the
information in stbt.conf, and have our custom libraries read from it.
Then if we have multiple set-top-boxes connected to a single PC, we
create a different stbt.conf for each one, and set STBT_CONFIG_FILE
appropriately in the environment of `stbt run`.

Note that `stbt.load_config` only reads the config files once, at the
beginning of `stbt run`, to ensure that the stbt script sees a
consistent view of the configuration files for the duration of its run.

Note that (unlike `stbt.wait_for_match` etc) stbt-run doesn't import
`get_config` into the top-level namespace of the stbt script, because
we want to encourage people to import dependencies into their scripts
explicitly (see commit 35bbf455).
stbt tv: New command-line tool to show live video on screen

`stbt tv` is useful when you have multiple systems-under-test and you
don't have a video multiplexer or switcher to connect them all to their
own TV monitor. With `stbt tv` you can view the system-under-test's
video output on your computer. This can't be used at the same time as
`stbt run`.
stbt screenshot: New command-line tool to capture a single screenshot

When you already have a large library of tests & helper functions,
writing a new test may only require one or two new template images, and
`stbt record` is overkill. This tool captures a screenshot from the
system-under-test in its current state.

This tool is also extremely useful immediately after a stbt script has
failed due to a false-failure from stb-tester's image-matching
algorithm: Unlike the screenshot generated by `stbt run` when a
`wait_for_match` fails, this screenshot won't have the "best match"
yellow rectangle drawn on it.
stbt templatematch: New command-line tool to compare two images

This is useful for experimenting with different `wait_for_match`
parameters, and for writing unit tests for your stbt scripts.

(Whenever we write a stbt script that has to override the wait_for_match
`noise_threshold`, we capture a screenshot and write a unit test —using
`stbt templatematch`— that will fail if the image comparison starts
matching _without_ the custom `noise_threshold`. That way we'll know to
remove the custom `noise_threshold` if the templatematch algorithm is
improved in a future release of stbt. The unit test also serves as
documentation for why the custom `noise_threshold` was necessary.)
Merge branch 'auxiliary-tools'

Implements some of the tools proposed in
https://groups.google.com/d/msg/stb-tester/AI8kEmIY-z8/xgCaonXNeDAJ

* auxiliary-tools:
  stbt templatematch: New command-line tool to compare two images
  stbt screenshot: New command-line tool to capture a single screenshot
  stbt tv: New command-line tool to show live video on screen
  New function `stbt.get_config` for stbt scripts to read from stbt.conf
  stbt config: New command-line tool to read a value from stbt config file
rpm spec file: Bump stb-tester version to 0.12
tests/test-stbt-run.py: added missing hyphen in test_get_config()

Due to a missing hyphen, the test_get_config() was calling `stbt run`
(which launched /usr/libexec/stbt) instead of the `stbt-run` in the
top-level source directory.
README: Link to DirectFBSource GStreamer element
README: Minor correction: We only support one *lirc*-based ir blaster per PC
stbt-run: Add missing newline to log message
tests for stbt screenshot/templatematch/tv should test source version

...not the installed version of stbt.

The tests execute `stbt-screenshot` (note the dash) to pick up the
program from the source folder (which I'll call "$srcdir").
`stbt-screenshot` was then executing `stbt run`. Because `make check`
sets `PATH=$srcdir:$PATH`, during the tests this would find
`$srcdir/stbt`. But `$srcdir/stbt` has hard-coded paths to
`$prefix/libexec/stbt/stbt-run` and thus the test ends up running
the *installed* version of `stbt`.

If `stbt-screenshot` etc. call `stbt-run` instead of `stbt run`, it will
work correctly in both cases: from the installed location, and from the
unit tests.

This commit also fixes two unrelated issues:

+ The GStreamer plugin wasn't being rebuilt when you ran `make
  check-integrationtests` instead of `make check`.

+ Set up the PATH for running tests in `tests/run-tests.sh` instead of
  in the `make check-integrationtests` recipe. This is so that you can
  run `tests/run-tests.sh` directly without having to manually set up
  the correct environment.