stbt._match: Performance optimisation by using "pyramid" matching

The most expensive part of the image-matching algorithm is the call
to OpenCV's "matchTemplate" function, which compares the template image
against each possible position within the source image.

The "pyramid" algorithm downsamples (shrinks) the source & template
images to half their width & height (thus 1/4 of the total pixels)
before passing them to the matchTemplate function. If a likely match is
identified, we then call matchTemplate with the source & template images
at their full size, but restricting matchTemplate's search to the areas
identified as potential matches during the previous level. This process
can be repeated more than once, for example starting from images 1/4 of
the original width & height (1/16 the total pixels).

At the smaller image size, if we identify a match, we always check again
at the larger size. So this algorithm is purely a performance
optimisation; it doesn't change the original behaviour.

At the smaller image size, if we *don't* identify a match, we return a
"no match" decision immediately. This might introduce differences
between the smaller images that weren't present in the originals; one of
the next commits accounts for this by making the match threshold more
tolerant at the smaller levels of the pyramid.

Although this optimisation shouldn't change the behaviour, it's always
possible that I accidentally introduced bugs. So you can disable this
optimisation by setting "match.pyramid_levels" to 1.

Once you add the fixes in the next 3 commits, all stb-tester's unit
tests continue to pass; I have also tested the functionality against a
private collection of 60 template images and 100 source images, and all
6,000 comparisons continue to yield the correct result (checking every
template against every source image; some of the combinations are
expected to match, others are expected to not match because every
template is not present in every image).

The performance improvement, as measured by
tests/run-performance-test.sh against a 720p video:

    before: 3.0fps; after: 35fps

But note that every frame in the video was a "no match", so the image
matching algorithm returned early. Measured using the same script and
video, with a template of the same size that does match:

    before: 2.8fps; after: 19fps

Each measurement was from the best of three runs, on my laptop with
dual-core 1.8GHz Intel Core i7, with the next 3 commits also applied,
and with templates sized 160x57 pixels (large enough for all 3 pyramid
levels to be used).
stbt._match: Don't halve the size of very small template images

This fixes some false negatives with small (~25px) template images.

Note that the source image must always be larger than the template
image, so we don't need to check that `image_pyramid` has as many levels
as `template_pyramid`.
stbt._match_template: Fix for large templates

If the source and template images are exactly the same size, the
`roi_mask` will be exactly 1x1. `cv2.findContours` doesn't return *any*
contours from images that are less than 3 pixels wide or high.

This fixes the following unit tests:
* test_wait_for_match_confirm_threshold_affects_match
* test_wait_for_match_erode_passes_affects_match
stbt._match_template: Lower threshold for downsampled images

Downsampling the images for the pyramid templatematch can cause images
that would match at the original size to not match at the smaller size.

I have only seen this happen in the self-test test_press_visualisation,
which has images with very thin, very high contrast text. At the
original size, the template matched with first pass certainty of 1.0; at
half the size, the certainty was 0.799, just below the default threshold
of 0.8.

To avoid matching images that didn't match before, we still use the same
threshold when checking the images at the full size (i.e. the last step
of the pyramid algorithm); but at the intermediate steps dealing with
downsampled images, we lower the threshold by 0.20. This number is
purely based on the result from the test_press_visualisation self-test,
which is the only failure of its type I have observed with the new
pyramid algorithm, after checking many images in a private collection.

In theory this has a performance impact, because the region of interest
processed at subsequent levels in the pyramid algorithm will be larger.
But I couldn't measure any difference with tests/run-performance-test.sh
(perhaps because the particular source video & template image I was
using don't present many matches between the thresholds of 0.6 and 0.8).
"stbt run -vv" output includes html guide to understanding the debug images

"stbt run -vv" generates debug images to
"./stbt-debug/detect_match/<frame_number>/".

These images are numerous, and difficult to understand. Now we also
generate "./stbt-debug/detect_match/<frame_number>/index.html" which
presents the images in the correct order, notes the decision taken at
each point of the algorithm, and explains the images somewhat.