templatematch: Remove no-op call to gst_templatematch_load_template

We have just set filter->template to NULL, so
gst_templatematch_load_template did nothing.
templatematch: Pass video through when nothing to match against

The early return was bypassing the call to gst_pad_push. With no
filter->template (and thus no filter->cvTemplateImage) the rest of this
function is essentially a no-op (except for the call to gst_pad_push).

This (plus the previous commit) allows templatematch to be
enabled/disabled without removing it entirely from the pipeline, by
setting/unsetting the template property.
templatematch: Allow changing template property on the fly

Previously changing the template property resulted in an exception
thrown from cvMatchTemplate, because "dist_image" (the intermediate
match-certainty-distribution) was the wrong size (because the
template image size had changed).

Locking has also been added to allow changing the properties (e.g. the
pattern to match) while the pipeline is playing.

 * gst_element_post_message is moved outside of the lock, because it will
   call into arbitrary user code (otherwise, if that user code calls into
   gst_templatematch_set_property on this same thread it would deadlock).

 * gst_template_match_load_template: If we fail to load the new template
   we still unload the previous template, so this element becomes a no-op
   in the pipeline. The alternative would be to keep the previous template;
   I believe unloading the previous template is a better choice, because it
   is consistent with the state this element would be in if it fails to
   load the very first template at start-up.

Thanks to Will Manley for the bulk of this work; any errors are probably
mine.
templatematch: Match rectangle grows redder with increased match certainty

This is useful for debugging your matches as it indicates how certain the
match was in addition to its position.
templatematch: Produce a warning message if we can't load a template image
templatematch: mark pads as proxy caps

Allows negotiation to happen properly
opencv templatematch: Set caps to BGR order

templatematch operates on BGR data. In fact, OpenCV's IplImage always
stores color image data in BGR order -- this isn't documented at all in
the OpenCV source code, but there are hints around the web (see for
example
http://www.cs.iit.edu/~agam/cs512/lect-notes/opencv-intro/opencv-intro.html#SECTION00041000000000000000
and http://www.comp.leeds.ac.uk/vision/opencv/iplimage.html ).

gst_templatematch_load_template loads the template (the image to find)
from disk using OpenCV's cvLoadImage, so it is stored in an IplImage in
BGR order. But in gst_templatematch_chain, no OpenCV conversion
functions are used: the imageData pointer of the IplImage for the video
frame (the image to search in) is just set to point to the raw buffer
data. Without this fix, that raw data is in RGB order, so the call to
cvMatchTemplate ends up comparing the template's Blue channel against
the frame's Red channel, producing very poor results.
tests: templatematch: add test to check that we use the correct rgb format

templatematch should use the same RGB format that opencv uses (BGR), make sure
we keep it that way with this test.

https://bugzilla.gnome.org/show_bug.cgi?id=678485
tests: files: adds missing file from previous commit

This is required for the templatematch test to work
tests: gitignore: update with new tests
glmemory: reenable the texture_rg support for !eagl

The GST_GL_HAVE_PLATFORM_EAGL is always defined we need to compare
against the value instead.
glimagesink: keep the uploaded buffer around on successful redisplay

We might need it later to perform a redisplay.  GstGLUpload will take
of releasing the previous buffer when it receives a new buffer.

https://bugzilla.gnome.org/show_bug.cgi?id=733726