extra/runner selftests: Increase timeout

`test_runner_sigint_twice` was seen to fail with:

    error: Didn't find 'test.py...' after 2 seconds
extra/runner/run: Take screenshot on *failure*
extra/runner/templates/testrun.html: Cleanup: Whitespace & field order

In the next two commits I'll be adding more code to the "failure reason"
and "extra columns" fields, so some vertical whitespace will make things
a little bit clearer.
extra/runner: Web server to allow interactively editing the failure-reason

If you run `server 0.0.0.0:5000` from the directory containing the
testrun results, you can then view the html reports at
`http://hostname:5000/` and double-click on the "failure reason" field
(in the right-hand test-run details pane) to edit it. Your change will
be POSTed to the web server, which will update the underlying
`failure-reason` file and the testrun and summary `index.html` files.

Note that if you don't want the interactive editing feature, you can
still view the html report locally (using a `file:///...` url), or you
can serve the report as static html files with a web server like apache.

You have to press "refresh" in your browser to see the failure-reason
change reflected in the summary table. This is because the test-run
details html is in a separate iframe, and I don't know how javascript in
the iframe can access the parent document.

`server` saves the user-given failure reason to `failure-reason.manual`,
so that re-running `report` won't overwrite the user's failure reason.
If `failure-reason.manual` exists it is displayed in the reports instead
of `failure-reason`.
extra/runner/templates/testrun.html: Cleanup: Extract in-line styles
extra/pylint.sh: Avoid extra blank lines in output from `make check`

Commit 72ab49b6 added this `echo` line to avoid the clutter of pygobject
deprecation messages we can't avoid. But it had the effect of printing
an additional blank line for files that *didn't* print that deprecation
message.
test_that_verbos*: Don't use source-pipeline from *user's* configuration

It didn't affect the result of these tests, but it was very confusing
to the person who ran `make check` to see a window pop up briefly with
real video from a real capture card.
tests/test-run-tests.sh: Test the helper functions used by the tests

This file was missing from commit 56aa1db9 (`test_killtree`, defined
here, was used by `test_runner_killtree` in 56aa1db9).
extra/runner/server: Generate directory listings

If the requested path is a directory that doesn't contain an
`index.html` file, generate a directory listing, much like apache's
mod_autoindex.

This allows you to run `server` from one directory (or more) *above* the
directory where you ran `run` (i.e. the directory containing the testrun
results), to serve results from multiple different test "sessions".

I implemented the directory listing myself instead of using Flask's
AutoIndex plugin[1] because of deployment considerations: If I ever
choose to install `extra/runner` in the official stb-tester package I
don't want to be installing things like `flask-autoindex` with `pip`
(`flask-autoindex` isn't available in Ubuntu's package repositories, for
example). Also my implementation achieves much the same result with far
less code than Flask-AutoIndex.

[1] http://pythonhosted.org/Flask-AutoIndex/
extra/runner/templates/testrun.html: Fix incorrect link from 56aa1db9
extra/runner/run: Make `exit-status` available to user `post_run` script
extra/runner/run: Save `stbt` version to `stbt-version.log`
extra/runner/server: Serve ".log" files as "text/plain"

When `server` is used to serve all files (i.e. `server` isn't proxied
behind a web server like apache) the browser would download these files
to disk instead of displaying them in the browser.
extra/runner/server: Sort directory listings alphabetically
extra/runner: "Notes" field that can be edited interactively

This is for arbitrary user notes, entered via the web interface.

This information is stored in the file "notes.manual". Unlike
"failure-reason" (created by the automatic classifier script) and
"failure-reason.manual" (containing the text manually entered by the
user), there is no "notes" file, only "notes.manual". There might be
other "*.manual" files in the future, hence the changes to
`Run.__init__` and `Run.read`.
extra/runner/report.py: Cleanup: Move `strip()` into `Run.read`

So that each caller of `Run.read` doesn't have to do it.
extra/runner: Handle unicode input from web form

The javascript in static/edit-testrun.js sends the POST request with
utf-8 encoding (at least according to my tests on Firefox). The
`*.manual` files are only created from such user input via this `server`
script, so they will also always be utf-8.
extra/runner/report: Exit early on invalid arguments

Otherwise this would try to run `report.py $(dirname $arg)/index.html`
to generate the summary report, which would fail with a confusing python
backtrace if the argument was a directory that didn't contain any
testruns.
extra/runner/run: Export `PYTHONUNBUFFERED=x` to user hooks' environment

Setting `PYTHONUNBUFFERED` to any value prevents python from buffering
standard output, which causes wrong timestamps in the log files when a
python script's output is piped through `ts`.

This change means that if any scripts called from `run` (like the
user-specified pre-run, post-run, and classify scripts) use the same
`ts` technique, they won't have to set `PYTHONUNBUFFERED` themselves.
I'll use this in the next commit.
extra/runner/run: If NoVideo, check Blackmagic video-capture hardware freeze

Sometimes the Blackmagic video-capture card fails and never delivers
video again until the PC is rebooted. If this happens we don't continue
running any tests (because they would all fail; restarting the PC
requires human intervention).

We can detect this by running a capture with `GST_DEBUG` enabled. If the
card is functional, then the message "VideoInputFrameArrived" is printed
to stderr *even if the Blackmagic card has no video on its input* (for
example if the set-top box is off). But if the card has failed then the
message is never printed.

For each of the following scenarios the GStreamer debug output looks
like:

* Working Blackmagic card, video source (the system under test) is on:

    activating push
    activatepush
    VideoInputFrameArrived: Frame received [<timecode>] - Valid Frame - Size: <n>

* Working Blackmagic card, video source is off:

    activating push
    activatepush
    VideoInputFrameArrived: Frame received - No input signal detected

  (Sometimes even when the video source is off, you can get
  "VideoInputFrameArrived: Frame received [<timecode>] - Valid Frame".
  Maybe this is only when the Blackmagic card has been configured to
  deliver the last seen frame when there is no video; I'm not sure.)

* Blackmagic card in use by another process (e.g. `stbt tv`):

    enable video input failed

  (and the GStreamer pipeline exits)

* Blackmagic card crashed (requiring a reboot of the PC):

    activating push
    activatepush

  (and the GStreamer pipeline just hangs after that output; eventually a
  stbt function like `wait_for_match` will timeout and raise `NoVideo`).

Note also that this writes to `failure-reason.manual`, because
`failure-reason` can be overwritten if you (manually) re-run `report`.
This Blackmagic failure can only be detected "online" (at the time the
test failed, on the same system that ran the test).
`failure-reason.manual` was introduced in commit 56aa1db9 to store
failure reasons entered manually by the user via the web interface, but
it is useful in this case too. Hopefully the "manual" name isn't too
confusing.

Thanks to Aiman Baharna <aiman.baharna@youview.com> for figuring out
how to detect Blackmagic failures.