runner/templates/testrun.html: list images before log files

In failure instances, the screenshot is what you want to see first to
diagnose a failure. When collecting additional log files (using the
runner.extra-logging hook) the number of logs can push the screenshot and
other image artifacts off the bottom of the page (meaning the user must
scroll down the page for each test run they investigate.

This change simply makes the image artifacts be listed before any logs.
extra/runner summary report: Improve confidence interval display

Instead of:

    Passed: 74/80 (85% - 97%). Failed: 6/80 (3.4% - 17%). Errors: 0/80 (0% - 4.6%).

We now show:

    Passed: 74/80 (91±6%). Failed: 6/80 (9.4±6%). Errors: 0/80 (<4.6%).

Which is much clearer.
extra/runner summary report: Fix display of 100% in confidence interval

This displays "100%" instead of "1.0e+2%".

Note that the original code (in the "else" branch) is correct; only the
edge cases for k=0 and k=n (that I introduced in 2c333020) were
incorrect.
extra/pylint.{sh,conf}: Cleanup: Move "ignored-classes" to config file

The ignored checkers/messages are specified in the config file, so the
ignored classes belong there too.
make check: Disable pylint checks on numpy members

It seems that pylint can't figure out some magic done by numpy 1.8.0,
so stbt.py would fail `make check` with:

    E1101:410,16:detect_motion: Module 'numpy' has no 'multiply' member
    E1101:411,20:detect_motion: Module 'numpy' has no 'ones' member
    E1101:411,50:detect_motion: Module 'numpy' has no 'uint8' member
    E1101:413,26:detect_motion: Module 'numpy' has no 'uint8' member
    E1101:1013,11:gst_to_opencv: Module 'numpy' has no 'ndarray' member
    E1101:1018,14:gst_to_opencv: Module 'numpy' has no 'uint8' member
    E1101:1096,9:_match_template: Module 'numpy' has no 'ones' member
    E1101:1096,59:_match_template: Module 'numpy' has no 'zeros' member
    E1101:1099,18:_match_template: Module 'numpy' has no 'float32' member
    E1101:1161,39:_match_template: Module 'numpy' has no 'uint8' member
    E1101:1277,22:_log_image: Module 'numpy' has no 'float32' member
    E1101:1988,24:_fake_frames_at_half_motion.FakeDisplay.frames: Module 'numpy' has no 'zeros' member
    E1101:1988,53:_fake_frames_at_half_motion.FakeDisplay.frames: Module 'numpy' has no 'uint8' member
    E1101:1989,24:_fake_frames_at_half_motion.FakeDisplay.frames: Module 'numpy' has no 'ones' member
    E1101:1989,52:_fake_frames_at_half_motion.FakeDisplay.frames: Module 'numpy' has no 'uint8' member

These are genuine numpy members (I tried them all in ipython).

Pylint 1.0.0 and 0.28.0 both fail to understand numpy 1.8.0. I didn't
have this problem with earlier versions of numpy (1.6.2, at least).
api-doc.sh: Raise error if command line argument is missing

api-doc.sh expects a command line argument that it passes to `cat`.

If no command line argument is specified, `cat` hangs the execution
waiting for standard input, while the user of the script may think that
documentation is being generated.
stbt.press: Ensure minimum delay between subsequent key presses

Our usual way of ensuring that remote control keys are pressed at
the right time is:

stbt.press(key1)
stbt.wait_for_match(template)
stbt.press(key2)

Due to the enhanced template match algorithm introduced in commit
ac97d6dd, wait_for_match might return so fast that some set-top-boxes
miss the second key press. According to our measurement results
these set-top-boxes require a certain minimum delay between subsequent
key presses in order to register every key.

This commit adds a new optional parameter `interpress_delay_secs` to
`stbt.press` that specifies a minimum time to wait after the preceding
key press that `stbt.press` ensures. The default value of this parameter
is read from the parameter of the same name in the `[press]` section of
the stbt config file.
tests for stbt.press interpress delay read config from tests/stbt.conf

The pattern used by all these tests is to use a `$STBT_CONFIG_FILE` (set
by `tests/run-tests.sh` to `tests/stbt.conf`) that contains the same
defaults as `tests/../stbt.conf`. This is necessary because
`$STBT_CONFIG_FILE` overrides the user's
`~/.config/stbt/stbt.conf` (which has configuration outside of our
control, that could break the tests).

This commit makes `test_that_press_waits_between_subsequent_presses` and
`test_that_press_reads_default_delay_from_stbt_conf` use the same
pattern used by all the other tests. Otherwise, the user's configuration
might have a "source_pipeline" that doesn't work, and thus causes
`stbt-run` to fail.
tests: Add test_that_press_doesnt_wait_any_longer_than_necessary
Merge branch 'interpress-delay'

* interpress-delay:
  tests: Add test_that_press_doesnt_wait_any_longer_than_necessary
  tests for stbt.press interpress delay read config from tests/stbt.conf
  stbt.press: Ensure minimum delay between subsequent key presses
extra/runner summary report: Display ">99%" instead of ">100%"

Because ">100%" is confusing. Since we round to 2 significant figures,
">100%" really means ">99.x%".
stbt.py: Incorrect first-pass "matched" text in match visualisation debug output

`stbt run -vv` and `stbt templatematch -v` output an html file in
`./stbt-debug/detect_match/*/index.html` to aid debugging of match
problems.

For the first-pass result, this file was saying "Matched" even when it
didn't match.

Note that the first-pass of the matching algorithm uses a "pyramid"
optimisation, where it operates on smaller versions (higher pyramid
levels) of the source & template images; only if a match is found does
it try the next larger version (lower level) of the images. Thus, if
there exists a lower level, it means that the higher level matched.
At the lowest level, we check `first_pass_matched`.

Really all of this information should be passed to
`_log_image_descriptions`, perhaps using the observer pattern, so that
`_log_image_descriptions` doesn't have to figure it out by inference.

Note also that the `levels` passed in to `jinja2.Template.render` is now
used more than once, so it has to be a list, not a lazy sequence.
test_runner_results_server: Fix curl IPv6 failures

Depending on which network I was connected to when I ran the tests,
"test_runner_results_server" and
"test_runner_results_server_shows_directory_listing" would fail with:

    curl: (7) Failed to connect to localhost port 5787: Connection refused

Manually starting up the server and running curl in verbose mode
revealed the problem:

    $ extra/runner/server localhost:5787 &
     * Running on http://localhost:5787/

    $ curl -v http://localhost:5787/
    * Hostname was NOT found in DNS cache
    *   Trying ::1...
    [...]
    * connect to ::1 port 5787 failed: Connection refused
    *   Trying fe80::1...
    * Connection failed
    * connect to fe80::1 port 5787 failed: Connection refused
    * Closing connection 0
    curl: (7) Failed to connect to localhost port 5787: Connection refused

Removing the IPv6 entries for localhost from /etc/hosts fixes this, but
obviously it isn't the correct solution. So I've made the server and
curl both explicitly use 127.0.0.1 (the IPv4 localhost address).

My version of curl is 7.34.0. This curl bug is possibly the same as
http://curl.haxx.se/mail/lib-2012-03/0045.html

Other tests that use "localhost" (such as "test_irnetbox_proxy") but
don't use curl, don't suffer from this problem.
stbt.MatchResult: Refactor: Implement as class, not namedtuple

The user-facing Python API remains the same. I'm making this change so
that in the next commit I can add an optional argument to the
`MatchResult` constructor.

I also simplified a caller that instantiates `MatchResult` to use
positional instead of keyword arguments, to avoid unnecessary
repetition. Both the class definition and the caller are in the same
file, and anyway we shouldn't ever reorder the `MatchResult` arguments
because that would break backwards compatibility with user code in a
very confusing way.
MatchTimeout.screenshot is the exact frame that wait_for_match saw

...instead of a frame captured a split-second after the match failure.

Why? So that the screenshot saved by `stbt run` (when the user's script
raises a `MatchTimeout`) shows exactly the same frame that failed the
match. We have seen situations where a UI item is *just* too slow to
appear, and fails a `wait_for_match`, but appears in the screenshot --
very confusing to users. More annoying still, sometimes there are minute
differences (in colour? brightness? encoder artifacts?) between
subsequent frames, such that a false no-match causes a `MatchTimeout` to
be raised but the screenshot saved by `stbt run` does actually match.

Another practical use is that the `MatchResult.frame` returned from
`wait_for_match` can be fed directly into, for example, an OCR function.

`MatchResult` now has a `frame` member. Each `MatchResult` yielded by
`detect_match` includes the video frame that `detect_match` checked, and
`wait_for_match` uses this frame for the `MatchTimeout.screenshot`
parameter, instead of calling `get_frame` to fetch a new frame from the
GStreamer pipeline.

Notes:

* The match visualisation (the red or yellow rectangle drawn on the
  video output) is done on a different copy of the frame that is
  attached to the `MatchResult`, so that users of the
  `MatchResult.frame` see a pristine screenshot.

* In `wait_for_match` we disable the pylint warning W0631 ("Using
  possibly undefined loop variable 'res'") because we know that
  `frames` (and thus `detect_match`) will always yield at least one
  frame, and thus `res` will always be set after the loop.

* In theory we should also apply a similar change to `MotionTimeout`,
  for consistency's sake; but I am not aware of any practical need for
  that.
Show stbt.MatchResult frame=None deprecation warning

The deprecation warning introduced in eb658d20 wasn't shown by the
existing warnings filter. I have added the word "stb-tester" into all
other deprecation warnings in the stbt module, and changed the warnings
filter to match.
stbt.ocr: Perform Optical Character Recognition using Tesseract

Tesseract is an open-source (Apache License 2.0) OCR engine.

Note that we use tesseract's command-line interface instead of an
existing Python wrapper, to avoid licensing restrictions
(python-tesseract and pyocr are GPL) and deployment difficulties (none
of the python wrappers are available in mainstream Linux distributions'
package repositories, so stb-tester users would have to use `pip` or a
similar Python packaging system). To use `stbt.ocr` you only need to
install Tesseract, which is available in Fedora ("tesseract"),
Debian/Ubuntu ("tesseract-ocr"), and macports ("tesseract") package
repositories.

TODO: Replace the `_Rect` class used by the image processing code with
the new `Region` class.

TODO: Add more-convenient ways of specifying a region. For example,
search for a label using `wait_for_match`, then specify the region
immediately to the right of that label (offsetting the region by the
width of the label template image).

Note that the unit test `test_ocr_on_static_images` violates our
standard 80-character line width, but only for the tabular test
data (which is more readable that way), not for the code. I think this
is an acceptable violation of the standard. Note that pylint only
applies this exemption inside of the array literal that contains the
"pylint: disable" directive.
stbt.ocr: Can specify Tesseract's page segmentation mode

If you have narrowed the region down to contain a single line of text,
you will often get better results with the `SINGLE_LINE` mode.

We default to Tesseract's default mode (fully automatic page
segmentation, but no Orientation or Script Detection).
stbt.Position: Tidy up docstring
Merge branch 'ocr'

* ocr:
  stbt.Position: Tidy up docstring
  stbt.ocr: Can specify Tesseract's page segmentation mode
  stbt.ocr: Perform Optical Character Recognition using Tesseract
  Show stbt.MatchResult frame=None deprecation warning
  MatchTimeout.screenshot is the exact frame that wait_for_match saw
  stbt.MatchResult: Refactor: Implement as class, not namedtuple