stbt.py: Add section markers for Emacs

These "Control-L" characters are "form feed", which are considered as
whitespace by editors and the python interpreter. Emacs uses these
characters to navigate between sections or "pages" -- see
http://www.gnu.org/software/emacs/manual/html_node/emacs/Pages.html
stbt.py: Wait for GLib main loop to finish before exiting

This is a cleanup commit that shouldn't change the observable behaviour.
It is necessary for the next commit, where we wait for end-of-stream
events to be processed by all sinks in the pipeline before we exit.

Note that `on_error` will be called at most once, after which
`on_new_buffer` shouldn't ever be called because we have quit the GLib
main loop, so the checks in `tell_user_thread` are no longer necessary.
stbt record, stbt run: Don't hang when remote control initialisation fails

If the `--control` argument is invalid, or the control fails to make a
necessary network connection, etc., `stbt record` and `stbt run` would
hang since the change in commit 8a9196d5, because `stbt.teardown_run`
was never called.
stbt.teardown_run: Fix error when Display was never initialised

Without this fix, the new test "test_invalid_source_pipeline" would have
failed with:

    Traceback (most recent call last):
      File "/Users/drothlis/work/youview/stb-tester/tests/../stbt-run", line 45, in <module>
        stbt.teardown_run()
      File "/Users/drothlis/work/youview/stb-tester/stbt.py", line 643, in teardown_run
        _display.teardown()
    AttributeError: 'NoneType' object has no attribute 'teardown'
stbt.py: Send End-Of-Stream before exiting

And wait for the EOS be fully processed by all sink elements, to allow
any muxers and filesinks specified by the user in `--sink-pipeline` to
write any index or header information. Without this, video recordings
of the test run[1] might be corrupted or not be seekable.

We can't send the EOS event to the pipeline as a whole because some
source elements don't propagate the EOS event properly[2]. So we send
the EOS to the sink bin's sink pad instead[3]. Each sink element in the
sink bin will post an EOS *message* after the element has fully
processed the EOS event, and the sink bin will post an EOS message to
the pipeline once it has received EOS messages from *all* its sink
elements. The pipeline won't send an EOS message to the application
until all the bins have posted EOS messages[4], so we go ahead and post
an EOS message on the source bin's behalf.

The final `pipeline.set_state(gst.STATE_NULL)` doesn't seem to be
necessary, and in fact it prevented the EOS message from reaching the
application. After removing it I've tested with videotestsrc,
v4l2src (with the Hauppauge HDPVR) and decklinksrc, and I don't see any
harmful effects. That line had existed since the initial commit, in
`stbt-run`.

Note that if teardown is called in the middle of `restart_source_bin`,
`stbt-run` hangs because the sink bin fails to process the EOS event,
so the GLib mainloop is never quit. The log from `GST_DEBUG=*:6` says:

    Received event on flushing pad. Discarding

...referring to the EOS event received on the sink bin's sink pad, which
is in the "flushing" state.

The unit test requires `webminspector.py` from
http://git.chromium.org/gitweb/?p=webm/webminspector.git
with this patch (pending review):
https://gerrit.chromium.org/gerrit/#/c/59912/
If `webminspector.py` is not found, the test won't be run.

On OS X the recorded video is always invalid (perhaps a bug with the
vp8enc or webmmux elements), so don't try to run the unit test on OS X.

[1] e.g. with a sink-pipeline of:

        vp8enc speed=7 ! webmmux ! filesink location=video.webm

[2] In particularly decklinksrc, the GStreamer source element for
    Blackmagic Intensity Pro video-capture cards. This is fixed on the
    GStreamer 1.0 branch:
    https://bugzilla.gnome.org/show_bug.cgi?id=680700
    but stb-tester still uses GStreamer 0.10.

[3] This post on the mailing list was helpful:
    http://gstreamer-devel.966125.n4.nabble.com/Handling-EOS-in-a-branched-pipeline-tp2965563.html

[4] In debugging this I used `GST_DEBUG=*:6` and grepped for `eos` as
    suggested here:
    http://gstreamer-devel.966125.n4.nabble.com/Pipeline-Not-Shut-Down-After-End-of-Stream-tp4659955p4659957.html
stbt.Display.teardown: Cleanup: Remove unnecessary check

`self.pipeline` is created in `self.__init__`, so if that fails, there
won't *be* a valid `self` object to run this `teardown` method on.
stbt.Display.__init__: Cleanup: Use GStreamer property name instead of number

This way is self-documenting.
stbt.get_config: Accept `default` parameter

This is needed by the next commit.
Source-restart-on-video-loss behaviour is configurable, uses separate pipeline

Set `global.restart_source` in your stbt.conf to `True`. This is only
necessary if you're using the Hauppauge HD PVR (see b6135eca).

This commit also changes *how* the source is restarted. Instead of
wrapping the source elements in a bin, and disconnecting it from the
pipeline, recreating the bin, and adding the new bin to the pipeline,
we now run the single source element (i.e. v4l2src) in an entirely
separate pipeline that sends the GStreamer buffers to the application's
main pipeline over a localhost UDP socket. This has 2 benefits:

1. If your `--sink-pipeline` is recording a video to disk, that video
   spans source restarts, so now it contains the full test run. The
   timestamps won't reflect the times when there was no video, though.
   You will see a brief blue screen, which the HD PVR delivers briefly
   before shutting down.

2. Interrupting `stbt run` (e.g. pressing Control-C) while the source is
   being restarted no longer causes `stbt run` to hang. In the previous
   implementation, while the source is being restarted the sink bin was
   in "flushing" state so it ignored EOS events (see b7a37493).

This has only been tested with the Hauppauge HD PVR, which delivers
MPEG-TS. I didn't need to explicitly specify `video/mpegts` caps after
`udpsrc`.

It seems that the main application pipeline recovers from video loss
more quickly if we start that pipeline running *before* we start the
initial source pipeline. But this is anecdotal.

This doesn't have any unit tests, because I couldn't figure out how to
get videotestsrc working with udpsink/udpsrc. The previous
implementation didn't have any tests either.
Change "restarting source" messages from debug to warnings

If you're trying to make sense of a test run, these really need to be in
the log, even if you didn't enable `--verbose`.
stbt run: --save-video to record a video to disk

This is easier for the user than having to specify a sink-pipeline like:

    tee name=mytee \
    mytee. ! queue leaky=downstream ! vp8enc speed=7 ! webmmux ! \
        filesink location=video.web \
    mytee. ! queue leaky=downstream ! xvimagesink sync=false

The video is in WebM format, which is playable by modern browsers as
part of the HTML5 standard.

On Fedora, vp8enc is provided by gstreamer-plugins-bad-free, and
webmmux is provided by gstreamer-plugins-good.
Merge branch 'video'

"stbt run --save-video" records a video to disk (2ee7b003); the recorded
video is seekable (b7a37493); the recorded video spans multiple restarts
of the Hauppauge HDPVR (5a0770e6).

* video:
  stbt run: --save-video to record a video to disk
  Change "restarting source" messages from debug to warnings
  Source-restart-on-video-loss behaviour is configurable, uses separate pipeline
  stbt.get_config: Accept `default` parameter
  stbt.Display.__init__: Cleanup: Use GStreamer property name instead of number
  stbt.Display.teardown: Cleanup: Remove unnecessary check
  stbt.py: Send End-Of-Stream before exiting
  stbt.teardown_run: Fix error when Display was never initialised
  stbt record, stbt run: Don't hang when remote control initialisation fails
  stbt.py: Wait for GLib main loop to finish before exiting