stbt.get_config: Explicitly cast return value to `str`

`ConfigParser.get` always returns a string already, but this helps
`pylint` (a static analyser), which otherwise would fail when run on a
script that calls `stbt.get_config(...).split(":")`:

    xxx.py:nnn: [E1103] Instance of '_Chainmap' has no 'startswith'
                member (but some types could not be inferred)
`wait_for_match` etc: Fix race condition when specifying match parameters

This was manifesting as intermittent failures of the test
`test_wait_for_match_confirm_methods_produce_different_results`.

This is issue #24: https://github.com/drothlis/stb-tester/issues/24

The race condition is that the `template` property of the
`stbt-templatematch` GStreamer element is being set *before* setting the
`confirmMethod` property. Sometimes the GStreamer element manages to
process one frame using the new template, and post a message, before the
`confirmMethod` property is set. The default `confirmMethod` value
causes a different match result than what we expect with the value we
wanted to set.

HOW I DIAGNOSED IT
==================

This was easy to diagnose with the following patch:

   diff --git a/gst/gsttemplatematch.c b/gst/gsttemplatematch.c
   index bd115e2..6642b81 100644
   --- a/gst/gsttemplatematch.c
   +++ b/gst/gsttemplatematch.c
   @@ -503,6 +503,10 @@ gst_templatematch_chain (GstPad * pad, GstBuffer * buf)
          matched = FALSE;
        }

   +    printf("*** matched: %s\n", matched ? "true" : "false");
   +    printf("*** confirmMethod: %d\n", filter->confirmMethod);
   +    printf("*** template: %s\n", filter->template);
   +
        s = gst_structure_new ("template_match",
            "x", G_TYPE_UINT, best_pos.x,
            "y", G_TYPE_UINT, best_pos.y,

I got the following output:

    stbt-run: Searching for tests/known-fail-template.png
    *** matched: true
    *** confirmMethod: 1
    *** template: tests/known-fail-template.png
    *** matched: false
    *** confirmMethod: 2
    *** template: tests/known-fail-template.png

THINGS THAT DIDN'T WORK
=======================

    diff --git a/stbt.py b/stbt.py
    index 646b758..4aa18bf 100644
    --- a/stbt.py
    +++ b/stbt.py
    @@ -754,8 +754,7 @@ def Display.detect:
                 properties_backup[key] = getattr(element.props, key)

             try:
    -            for key in properties.keys():
    -                setattr(element.props, key, properties[key])
    +            element.set_properties(**properties)

                 # Timeout after 10s in case no messages are received on the bus.
                 # This happens when starting a new instance of stbt when the

It seems that `set_properties` doesn't set all properties atomically.

    diff --git a/stbt.py b/stbt.py
    index c5ddd26..bcdaf08 100644
    --- a/stbt.py
    +++ b/stbt.py
    @@ -655,8 +655,10 @@ def Display.detect
                 params_backup[key] = getattr(element.props, key)

             try:
    +            self.pipeline.set_state(gst.STATE_PAUSED)
                 for key in params.keys():
                     setattr(element.props, key, params[key])
    +            self.pipeline.set_state(gst.STATE_PLAYING)

                 # Timeout after 10s in case no messages are received on the bus.
                 # This happens when starting a new instance of stbt when the

Pausing the pipeline while we set the properties didn't make any
difference either. Maybe the `set_state` function doesn't block until
the pipeline is actually paused?

THE FIX
=======

This fix simply sets the `template` property after all the other
properties. This works because `detect_match` discards messages from the
GStreamer element if the message's `template` field doesn't match the
template we are looking for.

We do the same for the `enabled` property of the `stbt-motiondetect`
GStreamer element used by `detect_motion`. Note that
`stbt-templatematch` doesn't have an `enabled` property, because the
`template` property serves the same purpose.

This is a *temporary* fix because, in theory, the GStreamer element
could have posted a message *after* we've stopped reading messages but
before we set the `template` property back to null. If the next
`wait_for_match` uses the same template but with different match
parameters, it might read the old message from the bus and mistakenly
accept it.

A more robust fix would be to set some serial number property (*after*
setting the new template and all match-parameter properties), have the
GStreamer element include this serial number in the messages it posts,
and have the python application check that the serial number in the
messages matches the value it set.