stbt.get_config works from scripts run with `python`

(not just from scripts run with `stbt run`).

Before this commit, a python script calling `stbt.config` would give
different results if it was run with `python` or with `stbt run`. When
run directly with `python`, it wouldn't read the values from
`/etc/stbt/stbt.conf` (or the appropriate location for the host-wide
config file). This was because `stbt.get_config` was expecting the
environment variable `STBT_SYSTEM_CONFIG` to be set; this was set by
`stbt` (see `stbt.in`; the correct value for `STBT_SYSTEM_CONFIG` was
hard-coded into `stbt` when you'd run `make`).

This commit changes the mechanism for finding /etc/stbt/stbt.conf: Now
this value is hard-coded (again, at `make` time) into the default
read-only config file (e.g. /usr/libexec/stbt/stbt.conf -- see
1fc5016e).

In practice, any stb-tester script that uses the video-capture or
infrared control capabilities must be run with `stbt run`; but it's
conceivable for users to write helper scripts that only use
`get_config`.

A note on the `stbt.py` implementation: According to my experiments, you
can call `ConfigParser.read` multiple times without losing the
previously-loaded values, but this isn't documented. The
documentation[1] says to load defaults with `readfp` and then make a
single call to `read` passing in multiple filenames in an array.

[1] http://docs.python.org/2/library/configparser.html#ConfigParser.RawConfigParser.read

Fixes #17.
stbt-completion: Cleanup: Refactor XDG_CONFIG_HOME default value

...into a single line. The less we mutate existing variables the better.
make check-integrationtests: Don't stop at the first failure

tests/run-tests.sh now runs all shell functions whose name begins with
"test_", instead of specifying each test function explicitly.

I hadn't done this before because I wanted the tests to be run in a
particular order (specifically, to test that GStreamer worked at all
before carrying on with any other tests). But this was causing too
much code duplication in tests/run-tests.sh.

This will also allow me to introduce parallelisation into `make check`
in a future commit.
Run self-tests in parallel

Use GNU parallel to run the various unit tests in parallel. This cuts
`make check` time in half on my dual-core Core i7:

* `make check-integrationtests` went from 80s to 40s.
* `make check-pylint` went from 5s to 3s.

The implementation takes advantage of the fact that `tests/run-tests.sh`
and `extra/pylint.sh` will run a specific test (instead of all tests) if
it is named as a command-line argument.

I can't apply the same parallelisation to `make check-nosetests` because
its output is different if you run it once per file instead of once with
a list of all files (`make check-nosetests` only takes 1.3s to run,
anyway). I didn't apply parallelisation to `make check-bashcompletion`
either, because it takes 0.1s to run.

Note that moreutils also has a tool called "parallel", but it has a
different (and less convenient) command-line API. Fedora wisely don't
provide it in their moreutils package, so that you can install GNU
parallel without conflict.

Note that this implementation falls back to running the tests serially
if you don't have GNU parallel installed.
make check: Don't use PARALLEL environment variable

Commit 42d1d8aa uses PARALLEL if it is set in the environment, copying
the way that INSTALL and TAR are handled. This wasn't a good idea
because `parallel` uses `$PARALLEL` for its default options, so users
are likely to have PARALLEL set to something like "-j8".

Using `:=` instead of `?=` won't take the value from the environment,
but you can still override it with an explicit
`make check parallel=gparallel`.
tests/run-tests.sh: Cleanup: Remove all files in $scratchdir after each test run

I was trying to avoid `rm -rf $scratchdir` out of paranoia, in case
`$scratchdir` expanded to something like "/". But I think with this
I'm being sufficiently careful.
make check: Fix intermittent failures for tests that save screenshot to disk

These tests started failing intermittently since commit 42d1d8aa where
`make check` runs these tests in parallel. Both tests were creating
`screenshot.png` in the same directory, and were occasionally trampling
on each other. Now they use `$scratchdir` which is different for each
test.
make check: Run each test in a sub-shell to fix failures introduced by 9371c5d2

Commit 9371c5d2 had the test `test_wait_for_match_no_match` change the
working directory, so all subsequent tests failed when run sequentially.
(When run via GNU parallel, the problem didn't manifest because each
test is run in a different process.)

The solution is to always run each test in a sub-shell, so that a test
can freely modify its environment without affecting other tests.
test_stbt_motiondetect_*: Fix intermittent failures on heavily-loaded systems

On a heavily loaded system, the timeout in `run_motiondetect` was
kicking in before the `stbt-templatematch` GStreamer element had
processed any frames. This problem started to manifest since we run the
unit tests in parallel (see commit 42d1d8aa).

Now we use videotestsrc's `num-buffers` property so that the
`gst-launch` command exits after a certain number of frames have been
processed.
test_wait_for_match_confirm_method_none...: Fix intermittent failure

The glob pattern was catching `screenshot.png` created by another
test being run in parallel; but by the time the `wait_for_match` tried
to *use* that `screenshot.png` file, that other test had finished and
`screenshot.png` had been removed from disk.

This problem started to manifest since commit 42d1d8aa, where we run
the unit tests in parallel.
test_detect_match_times_out_during_yield: Fix intermittent failure

and actually *test* something. Previously the invocation of `stbt-run`
would always succeed (though it was occasionally failing on heavily
loaded systems because `timeout` kicked in before `detect_match` timed
out; now I've removed that timeout because it is completely
unnecessary).

Now the test asserts that `detect_match` only yields a single value,
(the timeout specified in `timeout_secs` should cause the `for` loop to
end after the first iteration).
make dist: Use `gnutar` automatically if it is found

`make dist` requires GNU tar for the `--transform` option.

`make dist` uses `tar` by default; on a GNU/Linux system, this is GNU
tar so it just works. On my OS X `tar` is BSD tar, but I can install GNU
tar as `gnutar` using macports.

Before this commit, I'd have to specify `gnutar` explicitly:
`make dist TAR=gnutar`.  With this commit, the Makefile will try to
figure out the right `tar` to use (if it finds `gnutar` it will use
that).

If `gnutar` isn't installed, the error message in the `make dist` recipe
still recommends specifying `TAR=gnutar`, as a hint that you should
install `gnutar`, or use `TAR=x` if you have installed GNU tar under a
different name.
tests/run-tests.sh: Cleanup: Use "$srcdir" instead of "$testdir/.."

For clarity. In a future commit I'll have a test case that uses
"$scrdir".
tests: Cleanup: Use "$srcdir" instead of "$testdir/.."

This cleans up uses of "$testdir/.." missed from the previous
commit (ccb20267).
stbt: Minor formatting change to usage message
test_wait_for_match_nonexistent_template: Fix intermittent failure

Seen on our Travis continuous integration service:
https://travis-ci.org/drothlis/stb-tester/builds/7600784

Presumably on a heavily-loaded system, the test timed out before
`stbt-run` had a chance to run the `wait_for_match` function.

This test doesn't need a timeout at all, because (if `stbt-run` is
working correctly) `stbt-run` will always terminate.  If `stbt-run`
is so buggy that it hangs, someone will notice that the test hangs!