Revert "Disable Travis CI (remove .travis.yml config file)"

This reverts commit 1ff14a15554867e6eaf6419a6aee2ced6fb807a6.

The original commit disabled Travis-CI because Travis-CI's version
of OpenCV (2.3) was causing a unit test to fail. Commit 4b301f9 allows
the test to pass on OpenCV 2.3, so we can enable Travis-CI again.
stbt.Display.frames: Always return at least 1 frame

"frames(timeout_secs=0)" would fail with a "Queue.Empty" exception if
called twice in quick succession.

The timeout to "Queue.get" is unrelated to the overall "timeout_secs" of
"frames" (and "detect_match", "detect_motion", etc). The latter are
based on the stream timestamp; the "Queue.get" timeout only has effect
when the GStreamer pipeline isn't delivering any video. There are 2
reasons why there isn't any video:

1. The HDPVR momentarily lost video input, so it switched off. See
   b6135eca. 10 seconds will be enough time to restart the pipeline
   once.

   (Note that we don't want to implement the pipeline restarting
   behaviour here inside "frames" because we want to restart the
   pipeline as soon as video loss is detected, not only when the user's
   script calls "frames". The current implementation listens to
   "underrun" signals from the GStreamer pipeline, in a separate
   thread).

2. The system-under-test isn't delivering video. This might be expected,
   for example if the test script has rebooted the system-under-test. In
   that case your test script would say something like:

       restart_system_under_test()
       wait_for_match('splash_screen.png', timeout_secs=30)

   We want to allow those 30 seconds for video to reappear. In this
   commit's implementation it's possible that we allow a much longer
   timeout:

   * The first 29 seconds of frames *do* have video, but
     "wait_for_match" doesn't find a match.
   * Then in the 30th second we lose video, and we allow an additional
     30s timeout to get the next frame.

   But I don't think that's a big problem. If a test permanently loses
   video it will take a bit longer to fail, that's all.

This commit also gives a "no video" timeout the same behaviour (as seen
by the caller) as a timeout based on the stream timestamps: The
generator returns. Callers like "wait_for_match" can then choose to
raise an Exception like "MatchTimeout".
stbt.Display.frames: Document format of yielded images
stbt.Display.frames: Disable timeout by default

Note that the public API to this function is via "detect_match",
"wait_for_match", "detect_motion", etc. Those functions all continue to
take a default "timeout_secs" of 10, which they pass on to "frames". So
existing users won't be affected. New users will be able to use frames
to get an unlimited supply of frames, if they so desire. (At least,
they *will* be able to once we make "frames" publicly accessible.)

Note however that the "no input video" timeout of 10 seconds will still
apply.

The unit test takes 12s to run, because the previous default timeout was
10s. Hopefully this won't increase the total runtime of the test suite
too much, at least if you install GNU parallel (see 42d1d8aa).
make check: Force GNU parallel's GNU mode

Fedora 18 sets the "--tollef" flag in /etc/parallel/config, which forces
GNU parallel to behave like the moreutils parallel. We explicitly want
GNU parallel, which behaves like xargs (it takes each command's
arguments on standard input).
Revert "README: Update required OpenCV version to 2.4"

This reverts commit 5455ac04d7824bb5a297ddd6aed0f3f8d55b6ae2.

It turns out that it wasn't exactly a bug in OpenCV < 2.4, but incorrect
use of the API on our part. See 4b301f92 for details.
Revert "rpm spec file: Require opencv >= 2.4"

This reverts commit c25d743cbb258ba26695f493a2c6f35181d45d9d.

It turns out that it wasn't exactly a bug in OpenCV < 2.4, but incorrect
use of the API on our part. See 4b301f92 for details.