stbt batch summary report: Better highlighting of selected row

Instead of colouring the selected row blue, make it the same colour it
already is (green/red/yellow for pass/fail/error) but brighter, and
surrounded by a thick border. This border is open at the right-hand end,
with the row's background colour fading to white, to visually connect
the selected table row with the detailed results pane on the right-hand
side of the page.

We determined the new colours for the selected row by converting the
existing colour to the HSB colour-space and increasing the Brightness to
100%.

Various paddings are reduced (from the values set by Bootstrap) by the
size of the border to keep the same total box size. Note that there was
already a 1px top border on "td"s. "border-collapse: separate" on the
parent table is necessary to avoid a thin border at the right-hand end
of the selected row.
stbt._log_image_descriptions: print more accurate values for `certainty`

Both the user specified value for `match_threshold` and the value
calculated by opencv as the `certainty` were printed in the html debug
page rounded to 2 decimal places. This creates confusion when the two
values are printed as the same, which should mean that the templatematch
algorithm proceeds to the second pass, but this doesn't happen. Only from
looking at the console output can you see why the second pass didn't occur.

This commit modified the HMTL debug page so that

1) the `match_threshold` is printed as accurately as specifed (or the
   system default). The user is implicitly encouraged to not be more
   accurate that 2 decimal places by the system defaults (e.g. the default
   `match_threshold` is 0.80, not 0.8 or 0.800)

2) the calculated `certainty` is printed to 4 decimal places. I chose 4
   places rather than 3 because if you have a value such as 0.7995, the
   "%0.3f" python formatter will print "0.800", and although the trailing
   zeros imply rounding has occurred, it's more obvious to just give the
   extra decimal place. Obviously, 0.79995 will still round to 0.8000,
   but the chances of that happening are very small. Printing a full "%f"
   (6 decimal places) would be far too detailed.
test_ocr_on_live_video: Fix timeout when run under load

When run under heavy load (e.g. `make check` with GNU parallel
installed) this self-test could fail if the video pipeline hadn't
managed to start at all in the 10 seconds allowed by the call to
`get_frame` inside of `stbt.ocr()`.
Selftest that `run-tests.sh` isn't affected by user's $STBT_CONFIG_FILE

This test currently fails, but will be fixed by the next commit.
tests/run-tests.sh [fix]: unset STBT_CONFIG_FILE so no user override

Commit c83c42a2 "improved sandboxing" by creating an isolated environment
to run tests in. This included making a copy of test/stbt.conf and
putting into a pseudo system-default config directory. However, if the
user already has a STBT_CONFIG_FILE environment variable set, this will
take precendence over the new "system config".

This commit adds "unset STBT_CONFIG_FILE". I tested that unsetting an
environment variable does not carry through to the executing shell once
run-tests.sh has ended, so the user doesn't have to re-set it.
stbt-templatematch: use sensible, canonical variable names

This commit attempts to make the variable names used for the two image
file inputs and their corresponding numpy arrays, which previously were
mixed up and confusing.

For example, the file name of the template was stored in the variable
`template_image`, and then the image itself stored in `template`. Yet
`image` is the variable containing the `full_frame` numpy array, and was
given as the value to MatchResult.frame, and the not-yet used but optional
parameter MatchResult.image would (theoretically) be `template_image`.
Most confusing is the call to `stbt._match`, which had `image`, `template`
and `template_image` as arguments!

To make this much less confusing, I've adopted the naming convention used
by stbt templatematch's verbose debug output, where the input frame from
the video source is called `source` and the `template` is called `template`
and further clarified them with `_image` and `_file` suffixes.
stbt-templatematch: create MatchResult with `image` to avoid warning

Commit f51f6487 introduced the `image` parameter to the MatchResult class,
and added a DeprecationWarning which was invoked whenever a MatchResult
was created without `image` being set. However, the `image` parameter
wasn't added to stbt-templatematch, and so the verbose DeprecationWarning
came up every time you ran it.

Note that I could have added `image=template_image` and it would have
been valid, however this would print out "image=<Custom Image>", which
is pretty useless.
Merge branch 'stbt-templatematch--no-depr-warning'

* stbt-templatematch--no-depr-warning:
  stbt-templatematch: create MatchResult with `image` to avoid warning
  stbt-templatematch: use sensible, canonical variable names
  tests/run-tests.sh [fix]: unset STBT_CONFIG_FILE so no user override
  Selftest that `run-tests.sh` isn't affected by user's $STBT_CONFIG_FILE

Closes #142.
stbt.py: Make all logging output UTF-8

`stbt.ocr()` returns `unicode` strings objects and prints what it reads
to the logs using debug.  This in turn goes to `sys.stderr`.  If OCR has
read any characters outside of the ASCII subset of Unicode (the default
encoding with Python 2) calling `debug` could cause a
`UnicodeEncodeError`[^1].

With this commit all logging output is written as UTF-8.  I think this is
reasonable as it may be consumed by machine rather than a human and we
are unlikely to translate these debugging messages.  The same is not true
of the uses of `sys.stderr` still in stbt.py as they are interactive and
intended to be read by the user.

[^1]: By default whether you get a `UnicodeEncodeError` depends on the
      environment, whether stderr is connected to a TTY amongst other
      things.  So you could get a `UnicodeEncodeError` when writing to a
      file, but not at the terminal!
OCR: refactor into seperate _tesseract function

This will be useful for adding additional functions which use tesseract.
OCR: Add optional "lang" argument

Different languages use different glyphs, have different charactor
frequencies and most dramatically have different words in their
dictionaries.  Our OCR engine uses knowledge of the language it is
attempting to read to resolve ambiguities and to weight different
possibilities.

This commit adds an optional argument "lang" to `stbt.ocr` so this
information can be passed through to the underlying OCR engine.
OCR: Return utf-8 object rather than string

Tesseract outputs utf-8 encoded text files.  This allows it to represent
characters outside of 7-bit ASCII such as "£", ligatures, etc.  Up till
now stbt.ocr has also returned strings with the content encoded in utf-8
within.  This is unhelpful if you want to compare against known strings
in a test script.  For example, previously:

    assert '£100' == stbt.ocr()

Would fail as '£100' cannot be represented in 7-bit ASCII.  and:

    assert u'£100' == stbt.ocr()

Would fail as stbt.ocr would return '\xc2\xa3100'.

With this change `stbt.ocr()` would now return u'£100' which is clearer
and simpler to deal with.  This is technically an API break but I don't
expect it to break any real-life test cases.
OCR: Report region searched within in debugging

This is particularly useful if the region is not hard-coded in the test
scripts but generated on the fly from what can be seen on screen.

I've had to disable pylint's E1103 as it was giving false positives with
pylint 0.25 on Travis but not with pylint 1.1.0 on my machine.  The errors
were of the form:

    E1103:715,21:_tesseract: Instance of 'Region' has no 'y' member (but
                             some types could not be inferred)

Which sounds pretty false-positive prone to my ear anyway.
OCR: Scale image up 3x before passing to tesseract

Reduces error rate by a factor of 6 in testing.  See blog post "Improving
OCR Accuracy" for more information:

[1]: http://stb-tester.com/blog/2014/04/14/improving-ocr-accuracy.html
OCR: Normalise similar looking but meaning free charactors from tesseract

Tesseract sometimes has a hard job distinguishing certain glyphs such as
ligatures and different forms of the same punctuation.  We strip out this
superfluous information improving matching accuracy with minimal effect on
meaning.

This means that `stbt.ocr()` gives much more consistent results improving
reliability when matching against known text or when comparing read text
between invocations of `stbt.ocr()`.

See blog post "Improving OCR Accuracy" for measurements and more
information:

http://stb-tester.com/blog/2014/04/14/improving-ocr-accuracy.html
Merge pull request #146 from wmanley/ocr-accuracy

OCR improvements
stbt run: Dump pipeline-error debug from the right pipeline

If you define the environment variable `GST_DEBUG_DUMP_DOT_DIR` and a
GStreamer error occurs, `stbt run` will dump a Graphviz dot file with
debugging information (see 7b3eaf33). Previously we always dumped
debugging information for the *source* pipeline, even if the error came
from the *sink* pipeline.
stbt batch run: Classify blackmagic failure correctly

The classification for errors due to the Blackmagic Intensity Pro
video-capture card hasn't worked correctly since we ported stbt to
GStreamer 1.0 in commit a83333a2.

Also the "blackmagic card in use by another process" detection logic
hasn't worked since the blackmagic device moved from /dev/blackmagic0 to
/dev/blackmagic/dv0 -- presumably this changed with the recently
released blackmagic 10.0 driver. We look at both locations, thus
providing an upgrade path to users (upgrade stb-tester first, then
upgrade the blackmagic driver -- if you care enough about getting this
error classification right).

Thanks to Lewis Haley for the bug report and for the detailed solution.
Fixes #144.
Merge pull request #148 from drothlis/blackmagic-classification

stbt batch run: Classify blackmagic failure correctly