extra/runner: Move important data-gathering from `report` to `run`

This data must be collected immediately after the test-run has ended:

* The template must match the actual template used in the test; if we
  wait, the test script repository might be updated to contain a
  different template.
* The backtrace must match the libraries installed on the system at the
  time the test was run.

For these reasons, these don't belong in `report`; `report` can be
re-run over old test-run directories at any time.

This cleanup will help me to keep the different responsibilities clearer
when I introduce user hooks for custom logging, classification and
recovery procedures.
extra/runner: Record hardware sensor stats at end of each testrun

In case there is some correlation between test failures and high
temperatures (or other hardware factors). Note that this only works if
the `lm-sensors` package (`lm_sensors` on Fedora) is installed.

Based on a patch by Aiman Baharna <aiman.baharna@youview.com>.
extra/runner: Hooks for user-specific logging, classification and recovery

First read this commit's changes to `extra/runner/README.rst`.

For example, `pre_run` might start capturing network traffic, `post_run`
stop the network capture and close the dump file, and `classify` analyse
that file, extract the time taken by certain network requests, and add
that information to the file `extra-columns` so that it appears in the
generated HTML report. `recover` might detect that the system-under-test
had crashed, and power-cycle it.

Notes & details
===============

Sequence of invocation of a single test run (with user hooks in CAPS):

    PRE_RUN -> stbt run -> POST_RUN ->
    built-in classify -> CLASSIFY -> RECOVER -> report generator

Sequence when you invoke `report` manually at a later date to regenerate
the report:

    built-in classify -> CLASSIFY -> report generator

The order of the particular tasks performed after a test-run is
important. The following tasks must be done as soon as possible:

* Calculate the test-run duration.
* Read hardware temperature sensors.
* Take a screenshot (before UI elements like a miniguide have timed out
  and disappeared). This can take a second or two while the
  video-capture hardware spins up, so it is done after the previous two.
* Gather any user-specific logs. We don't know how long this will take,
  so it is last on this list, but it may do things that are more
  time-critical than anything on the next list.

The following tasks should be done now, instead of in `report`, because
`report` can be re-run much later (see 4196f2ad for details):

* Copy the template image from test script's source directory (if the
  test failed due to a match timeout).
* Get a backtrace from a core file (if the test dumped core).

Next we do `report`. `report` only depends on the information contained
in the testrun directory, so it can be run at any time. But we run it
now because `runner.recover` needs the `failure-reason` information
generated by `report`.

Next we run `runner.recover`. This must be run now (before we run the
next test) because it may need to reboot the system under test, or
perform some other recovery function, before the next test can be run.

Finally we run `report` again, so that the html report contains any
logs or `extra-columns` information created by `runner.recover`.

Limitations
===========

I'm generally not a big fan of callbacks, and I'm worried about the
highly structured, rigid sequence of these callbacks, but I haven't
thought of a simpler way.

One issue that this commit doesn't address is: What if you need live
data in order to know the `failure-reason`? Currently the classification
step in `report` (which includes the user `classify` hook) is supposed
to be runnable offline, so it should be able to make its decision purely
from looking at the log files collected earlier. But the
`failure-reason` might be "the video-capture card froze"; to determine
this requires analysing the live system that the test was run on.
A possible solution is for the `post_run` or `recover` hook to do this
analysis and record the failure reason in some particular way that
prevents subsequent runs of `report` from overwriting the failure
reason.
extra/runner/report: Handle long options

This is needed by the next commit.
extra/runner: Don't generate the html report twice

We need to run `report` before `recover`, because `recover` needs
the `failure-reason` generated by `report`.

And we need to run `report` again *after* `recover`, because the report
should contain any logs or `extra-columns` information generated by
`recover`.

I don't want to split the failure classification and html generation
into two separate scripts, because it is convenient for the user to
re-classify and re-generate the report for previous test runs by running
a single script (for example `report path/to/my-test-session/2013-*`).

The `--classify-only` and `--html-only` flags introduced in this commit
are undocumented, internal flags. The user doesn't need to care about
these; they are only to make `run` slightly more efficient.
extra/runner/report: Cleanup: Remove unnecessary `reason` function
extra/runner/report: Cleanup: Don't repeat regexp twice
stbt run: Include exception typename in stdout output

This information is used by the bulk-running & reporting scripts in
`extra/runner` to identify the type of failure, without having to rely
on specific wording in the exception message.
extra/runner: Report preserves newlines in "failure reason"

The "failure reason" can be generated by the user, so it can contain
multiple lines. Now "failure reason" is displayed just like the "extra
columns" information, which is also generated by the user.

Note that in the summary report (templates/index.html) the "failure
reason" is displayed without preserving newlines, but it is also
truncated to 30 characters so there's no need to preserve newlines as
the multi-line information won't all be visible.
TEMPORARY COMMIT: extra/runner/order.{dot,svg}

Graph of the dependencies between each step done by `run`. An arrow like
"A <- B" doesn't necessarily mean that B *runs* A; it means that B needs
A to complete before B can run.

Unfortunately I don't see how I can reduce the number of user hooks, or
simplify the rather complex sequence of: `run` calls `stop user
logging`, then `classify` (which calls `user classify`), then `recover`,
then `report`.