stbt.Display.teardown: Make debug message less scary-looking

"GLib mainloop is not alive" was the expected, correct behaviour but the
"not alive" part might suggest to someone unfamiliar with stbt internals
that there was a problem. This debug message is intended for debugging
(after the fact) test runs where the recorded video (if the user
specified "stbt run --save-video") is corrupted, possibly because the
GStreamer EOS message wasn't received and thus the GLib mainloop hadn't
terminated.
stbt.frames: Don't deadlock if iterator held twice from user code

If you call `stbt.frames()` while an iterator returned from a previous
call to `stbt.frames()` is still alive, attempting to iterate over the
second iterator would hang indefinitely:

    it1 = stbt.frames()
    for frame, timestamp in it1:
        ...
        break
    it2 = stbt.frames()
    it2.next()  # This deadlocks

The cause was the line `with self.lock in stbt.Display.frames:`.
This lock is intended to stop `stbt.Display.on_new_buffer` from acting
while the user code is processing frames; but it had the unintended
consequence of preventing the user from using 2 different `frames`
iterators.

The solution is to use a re-entrant lock: It can be acquired multiple
times by the same thread (in this case, the main application thread
running the user's script), and is only released once *all* of the
thread's calls to `acquire` have had their corresponding `release`.
Note that `stbt.Display.on_new_buffer` --what this lock is intended to
block-- is a handler for a GStreamer element signal, so it is always
called from the GStreamer element's own thread.

Fixes #36.
README: Remove "Setup tips" section

The immediately previous section links to
http://stb-tester.com/getting-started.html -- no need to duplicate that
information here. The man page (generated from this readme) is supposed
to be a concise reference; the extended help belongs on the website.