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.