Fix test_wait_for_match interlacing issue on OS X

On my OS X system the video seen by stbt has fine horizontal lines
through it -- some kind of interlacing problem. I can reproduce this
with the following gst-launch command, but only on my OS X system, not
on Linux. I don't know if the problem is platform-specific, to do with
my video sink, or just a bug in my specific version of GStreamer.

    gst-launch-1.0 videotestsrc ! \
        video/x-raw,format=I420,width=320,height=240 ! videoconvert ! \
        video/x-raw,format=BGR ! videoconvert ! autovideosink

(The conversion to BGR and back is to mimic what stbt does in its
internal pipeline; without that I can't reproduce the problem.)

Removing "format=I420" fixes the problem. On 0.10, "video/x-raw-yuv" was
necessary to be able to specify the width & height caps but it seems
that on 1.0 we only need "video/raw" and the format can be left
unspecified.
Revert is_screen_black.threshold change from a071a9cc

a071a9cc (Port to Gstreamer 1.0) increased is_screen_black.threshold
with the following comment:

> I've had to increase the default threshold in is_screen_black test as it
> seems, possibly with the move from `video/x-raw-yuv` to
> `video/x-raw,format=I420` that blacks aren't as black anymore, possibly
> as a result of GStreamer 1.0 choosing a different type of yuv in 0.10 or
> possibly due to changes introduced during the ffmpegcolorspace ->
> videoconvert change.

This isn't necessary after the previous commit (Fix test_wait_for_match
interlacing issue on OS X) which removed "format=I420" from the
self-tests' source-pipeline. Presumably the increased threshold won't
be necessary with real video-capture hardware either.
Merge pull request #121 from drothlis/fix-selftest-interlacing

Fix test_wait_for_match interlacing issue on OS X