stbt control: Output message: "Control" instead of "Listener"

This isn't "listening" using, for example, LIRC; it's using LIRC to
*send* the signals.
extra/runner: Send error messages from `sensors` to sensors.log

When run on a VM, `run` was printing the following error message to the
console after every test run:

    No sensors found!
    Make sure you loaded all the kernel drivers you need.
    Try sensors-detect to find out which these are.
extra/runner summary report: Fix jerky width change of details pane

Bootstrap's "affix" jQuery plugin started having an annoying behaviour
after baeb752c, where the width of the "details" iframe is different
when the window is at the top-most position, than when you scroll down
slightly.

"affix" is designed for fancy websites where an element moves normally
with the document as you scroll, but then "sticks" at the top once
you've scrolled enough. This is overkill for our needs, and a simple
"position: fixed" does the trick, without the flicker.
extra/runner summary report: Update "details" pane's height on window resize

Otherwise if you shrank the window, you wouldn't be able to scroll the
details pane; and if you grew the window, the details pane wouldn't take
up the full available height (until you selected a new row from the
table).

Also, the height calculation takes into account the 40-pixel-high black
title bar at the top of the window.
make doc: Don't mention parent class "object" in API documentation

Otherwise the API documentation (which is generated programmatically
into README.rst) would say:

    class MatchParameters(__builtin__.object)

instead of:

    class MatchParameters

ever since 65a38380. (I hadn't re-run `make doc` since 65a38380, which
is why the above change hadn't made its way into README.rst).
README.rst: Minor formatting change to reflect 65a38380

This commit is the result of running `make doc`, which updates the API
documentation in README.rst from the docstrings in stbt.py. I had
forgotten to run `make doc` when I made the changes in 65a38380.
Bump stb-tester version to 0.16

Note that the version number in the RPM spec file was already bumped in
2dfc88c2.
extra/runner/run: [bug] do classification before `check_capture_hardware`

...because `check_capture_hardware` greps the 'faiure-reason' file which
is created by running classify. This caused `check_capture_hardware` to
fail if using a device that uses the `v4l2src` Gstreamer element.
extra/vm: Install crtmpserver, an RTMP (Flash video) server, for VidiU

And an example source_pipeline configuration in
~vagrant/.config/stbt/stbt.conf.

Thanks to Aiman Baharna <aiman.baharna@youview.com> for the instructions
and the crtmpserver configuration.
extra/vm: Cosmetic change to ~vagrant/.config/stbt/stbt.conf

`restart_source` is False by default, so this commit doesn't have a
noticeable effect (unless the user changed `restart_source` in
/etc/stbt/stbt.conf, which is unlikely).

I found myself uncommenting the `#restart_source = False` line when I
wanted to use the HDPVR, but forgetting to change the `False` to `True`.
You shouldn't have to change *two* things (remove the comment *and*
change the value).
stbt.py: Handle VidiU H.264 encoder restart

By restarting the source pipeline when it receives an EOS (end of
stream) message. The "--restart-source" mechanism that we use to recover
from HD PVR failures isn't useful here, because after receiving EOS the
GStreamer queue in the source pipeline no longer sends underrun
messages. (The HD PVR's behaviour is that it stops sending frames but it
never sends an EOS.)

The Teradek VidiU is a video-capture device that takes HDMI in, and
streams RTMP out. We use `stbt run --source-pipeline='rtmpsrc ...'`.
When the resolution changes on the VidiU's input signal, *sometimes*
the VidiU goes through the following sequence of events:

        system under test       Vidiu front panel          Vidiu top-right indicator
       ----------------------- -------------------------- --------------------------
    1   Reboot                  Video not detected!        No video
    2   Splash screen appears   Video detected!            Live (briefly)
    3                           H264 blue light goes off   Not ready
    4   ...........................20 seconds.......................................
    5                           H264 blue light goes on    Starting
    6                                                      Live

At point 3 in the above table, the GStreamer rtmpsrc reports EOS (end of
stream).

So far we've only seen this when restarting the system-under-test. The
VidiU doesn't mind losing input video altogether (it just sends a blue
screen). It's when the system-under-test's splash screen appears and
disappears (because it's a different resolution that what came before &
after?) that we see this problem. But only about 50% of the times we
restart the system-under-test.

Test scripts affected by this VidiU behaviour (in our own body of test
scripts, only tests that reboot the system-under-test are affected) will
need to use a `wait_for_match` (or similar) with a timeout longer than
the 20 seconds it takes the VidiU to start streaming again.

Note that the self-test `test_that_frames_raises_NoVideo` would run
indefinitely after this change, because `videotestsrc num-buffers=1`
sends EOS so the source pipeline was continuously restarted. I tried
videotestsrc's `framerate=1/20` property, setting caps
(`! video/x-raw-yuv,framerate=1/20`), and the `videorate` element, but
none of them created the conditions I wanted.
`identity sleep-time=12000000` sleeps for 12 seconds of wall time (not
stream time) so it works even with our default sink-pipeline's
`sync=false`.