extra/vm: Install crtmpserver, an RTMP (Flash video) server, for VidiU

And an example source_pipeline configuration in
~vagrant/.config/stbt/stbt.conf.

Thanks to Aiman Baharna <aiman.baharna@youview.com> for the instructions
and the crtmpserver configuration.
extra/vm: Cosmetic change to ~vagrant/.config/stbt/stbt.conf

`restart_source` is False by default, so this commit doesn't have a
noticeable effect (unless the user changed `restart_source` in
/etc/stbt/stbt.conf, which is unlikely).

I found myself uncommenting the `#restart_source = False` line when I
wanted to use the HDPVR, but forgetting to change the `False` to `True`.
You shouldn't have to change *two* things (remove the comment *and*
change the value).
stbt.py: Handle VidiU H.264 encoder restart

By restarting the source pipeline when it receives an EOS (end of
stream) message. The "--restart-source" mechanism that we use to recover
from HD PVR failures isn't useful here, because after receiving EOS the
GStreamer queue in the source pipeline no longer sends underrun
messages. (The HD PVR's behaviour is that it stops sending frames but it
never sends an EOS.)

The Teradek VidiU is a video-capture device that takes HDMI in, and
streams RTMP out. We use `stbt run --source-pipeline='rtmpsrc ...'`.
When the resolution changes on the VidiU's input signal, *sometimes*
the VidiU goes through the following sequence of events:

        system under test       Vidiu front panel          Vidiu top-right indicator
       ----------------------- -------------------------- --------------------------
    1   Reboot                  Video not detected!        No video
    2   Splash screen appears   Video detected!            Live (briefly)
    3                           H264 blue light goes off   Not ready
    4   ...........................20 seconds.......................................
    5                           H264 blue light goes on    Starting
    6                                                      Live

At point 3 in the above table, the GStreamer rtmpsrc reports EOS (end of
stream).

So far we've only seen this when restarting the system-under-test. The
VidiU doesn't mind losing input video altogether (it just sends a blue
screen). It's when the system-under-test's splash screen appears and
disappears (because it's a different resolution that what came before &
after?) that we see this problem. But only about 50% of the times we
restart the system-under-test.

Test scripts affected by this VidiU behaviour (in our own body of test
scripts, only tests that reboot the system-under-test are affected) will
need to use a `wait_for_match` (or similar) with a timeout longer than
the 20 seconds it takes the VidiU to start streaming again.

Note that the self-test `test_that_frames_raises_NoVideo` would run
indefinitely after this change, because `videotestsrc num-buffers=1`
sends EOS so the source pipeline was continuously restarted. I tried
videotestsrc's `framerate=1/20` property, setting caps
(`! video/x-raw-yuv,framerate=1/20`), and the `videorate` element, but
none of them created the conditions I wanted.
`identity sleep-time=12000000` sleeps for 12 seconds of wall time (not
stream time) so it works even with our default sink-pipeline's
`sync=false`.
extra/runner/report.py: extra-columns appear in a predictable order

Prior to this commit, the order that a user's `extra-columns` appeared
in the html report wasn't consistent (see below for why). This commit
changes this so they appear in the order they appear in the
`extra-columns` file. Although this order is perhaps slightly arbitary,
it is an improvement on having no order at all.

Python dictionaries (which `collections.defaultdict inherits from), don't
have a consistent order (like a list) and so when iterating over different
instances of otherwise identical dictionaries you aren't guarenteed to
access the dictionaries' keys in the same order. See [1].

This commit changes report.py's Run.extra_columns attribute to use an
`OrderedDict`, instead of a `defaultdict`, which guarantees the order of
iteration over a dictionary's contents will always be the order they are
instantiated.

[1] http://www.laurentluce.com/posts/python-dictionary-implementation/