Travis: Cope with ftpmirror.gnu.org being down

Sometimes builds fail because ftpmirror.gnu.org is down.  With this change
Travis will fall-back to downloading GNU parallel from main GNU FTP site
instead if the mirrors fail.  Failing that we don't bother with GNU
parallel at all and gracefully degrade to running the tests in series.
Merge pull request #231 from wmanley/parallel-failure-robustness

Travis: Cope with ftpmirror.gnu.org being down
stbt.py: uri_to_remote: Make `display` argument optional

It is only required if instantiating a test remote, whereas we want to
use `uri_to_remote` more broadly in tests so the tests exercise the
production code-paths more often.
Tests: Pull _fake_lircd into seperate function

So we can use it in a subsequent test.  We also:

* Fix a potential race condition by removing a `sleep`
* Make `_fake_lircd` generally more robust to changes in stbt's
  implementation
* Fix a potential race condition with use of `tmpname()`
* Avoid polluting `/tmp` with old no-longer-listening sockets
* Make the `test_that_lirc_remote_is_symmetric_with_lirc_remote_listen`
  test more readable.
* Use multiprocessing rather than thread for improved robustness
stbt.py: stbt.uri_to_remote(lirc): Fix defaulting parameters

Commit 1cd69253 refactored the code for generating remote control objects
into a uri parser (using the `re` module). However, due to the fact that
in regex a glob '*' can match anything including an empty string, there
was a problem in that if the (optional) lirc socket parameter were omitted
"" would be passed to `new_local_lirc_remote` rather than the expected
`None`.

With this commit I change the pattern for optional parameters from `(.*)`
to `(.+)?` to ensure that the group will not match (`None`) rather than
matching the empty string (`""`).

Thanks to Lewis Haley for reporting, diagnosing and creating a candidate
fix in drothlis/#193.
stbt.py: stbt.uri_to_remote: Fix defaulting parameters

In the spirit of the previous commit this commit tightens up the
`uri_to_remote` regexes and ensures the tests are using `uri_to_remote`,
etc. to ensure the codepaths are better trod.

Having done this I came across some bugs in `VirtualRemote` parsing code
which had gone unnoticed.  I wonder if anyone is actually still using
`VirtualRemote`.  Perhaps they should be deprecated and then considered
for removal?
Merge pull request #199 from wmanley/remote-parsing

Remote parsing
debs: Fix build-dependencies

bd356cb seems to have introduced a typo, presumably due to a rebasing
problem in the list of build dependencies in the Debian control file.
This commit fixes it.

This patch emphasises the need for automated tests for our Debian/Ubuntu
packaging. much like we already have for Fedora.
Merge pull request #234 from wmanley/fix-deb-build-deps

debs: Fix build-dependencies
make install: Build stbt-gst-plugins.so if necessary

Fixes https://github.com/drothlis/stb-tester/issues/230
Makefile: `enable_stbt_camera=no` does what you'd expect

Previously only an empty value for `enable_stbt_camera` would disable
it.
Makefile: Cleanup: `stbt-camera` isn't a build artifact
Makefile: Cleanup spacing of ":" in rules

For consistency, and so that I can find the "install" target (as opposed
to other targets like "install-core" or "install" commands in recipes)
by searching for "install:".
Remove extra/fedora/Vagrant*

(These were to provide a host linux system for running docker in, to
build stb-tester's Fedora packages inside a docker container.)

With docker 1.3, boot2docker for OS X supports shared directories on the
host, so vagrant for a host linux system isn't necessary any more.
Anyway I have a Linux host system now.
tests/run-tests.sh: Cleanup: Rename internal variable

"test_installation" is ambiguous: Is it a verb (test the installation)
or a noun (the test installation)? If it's a verb, does it mean to test
the installation process or to test the version that's already
installed? (It's the latter.)
extra/fedora: Use the (semi-) official Fedora docker image
stbt config: Allow specifying multiple config files in $STBT_CONFIG_FILE

Convert $STBT_CONFIG_FILE to a list similar to $PATH and $PYTHONPATH
where the item specified at the beginning takes precedence.

Example:
    STBT_CONFIG_FILE=/path/to/temporary.conf:/path/to/permanent.conf
Parameters are searched for in temporary.conf first and permanent.conf
next.

Our use-case of this feature is to split the test specific config to a
set of permanent parameters that we version control, and a set of
temporary parameters that we are changing all the time:

- `source_pipeline` and `sink_pipeline` are specific to the video
  capture hardware that we hardly ever change. We would find it useful
  to track changes in capture device set-up, therefore we would like to
  version control these parameters and fetch them from a repository
  for every test run. They would be read from `permanent.conf` in the
  example above. They cannot go into the user config because we have
  multiple capture devices assigned to the same user.

- `control` depends on the model of the set-top-box, therefore it is
  frequently modified, and we would allow testers to change it as they
  like. It would go into `temporary.conf` in the example.
test_set_config: Test that set_config writes to the first config file

Test that `set_config` writes to the config file with the highest
precedence if multiple files are specified in $STBT_CONFIG_FILE.
Merge pull request #238 from szemate/multiple-config-files

stbt config: Allow specifying multiple config files in $STBT_CONFIG_FILE
make check: Run stbt-camera tests sequentially, and not at all if stbt-camera disabled

Fixes https://github.com/drothlis/stb-tester/issues/233

This implementation seems less error-prone than remembering to add
"skip" at the beginning of each new test case in test-camera.sh.

This also runs the stbt-camera tests sequentially. Running them in
parallel was *killing* the responsiveness of other apps on my computer,
with various python processes at 160%+ CPU usage.

Running sequentially might also make the tests more reliable (though
some of them are still consistently failing on my computer).