Screen/GStreamer: Protect against OpenGL context change during gst_init_check().

Apitrace'ing on Windows shows that GStreamer SDK, during gst_init_check()
(== at first-time initialization) creates and binds its own OpenGL context
on our thread behind our back, probably during some plugin enumeration for
OpenGL related plugins like gst-clutter. It fails to restore our OpenGL
context binding, so our code erroneously executes gl calls on the GStreamer
context instead of our own context --> Funny results ensue.

Add some PsychSetGLContext(win) calls after GSCheckInit() in OpenVideocapture
and OpenMovie implementations of the GStreamer backend. This guarantees that
our own Screen mastercontext is bound at the time we issue gl calls to setup
video capture or video playback, e.g., while we create and assign our YUV-I420
video decoding shaders.

Apitrace'ing shows that this stops the mess, and related gl error conditions
disappear in the trace. I assume this would fix the problems mentioned in
forum msg #16486 at first movie playback with pixelformat=6 after Matlab
was started. However, Matthew needs to verify this, as my VirtualBox Windows VM
is too broken wrt. shader operations to check this myself.

-> Screen.mex32/64 for 32/64-Bit Matlab on Windows rebuilt and apitrace tested.
-> Both Screens built against GStreamer SDK 2013.6.
-> Screen.mexw64 built against the MSCRT.dll.