Screen/Windows: Switch 32-Bit build from OSSBuilds Gstreamer to Gstreamer SDK.

Update build file to compile and link against 32-Bit GStreamer SDK
instead of 32-Bit OSSBuilds runtime. Enable GstEncodingProfiles for
video recording on 32-Bit Windows in source code. Update PsychStartup.m
to setup path to 32-Bit SDK.

-> Screen for 32-Bit Matlab on Windows rebuilt.
Core: Do not use stdint.h on MS-Windows, but #define needed types ourselves.

If we want to build mex files for Windows-PTB against the Microsoft
common C runtime library (msvcrt.dll) instead of the Microsoft Visual
Studio 2010 C libraries, we can't #include <stdint.h> as this will
cause various compile errors.

Therefore don't include stdint.h but #define the two needed constants
INT64_MAX and INT32_MAX ourselves.

Tested and shown to compile correctly with all mex files on 64-Bit
Matlab on Windows.
Screen('DrawText')/Windows: Only use process-global text encoding locales.

Turns out the Microsoft common C runtime doesn't support
_create_locale() and _free_locale() for creation of locale setting
objects. To remove the need for these functions and unify more code
paths, get rid of these local locale settings.

We now only use setlocale() + caching of locale settings to change the
process-global locale setting during text conversion as part of
Screen('DrawText'), ie., store backup copy of global setting, change
global setting to our wanted setting, perform decoding with that
setting, restore original process locale. This temporary change of
locale should hopefully not have side effects.

-> Allow buildings with MSCRT.dll
windowsmakeit64: Switch build of Screen.mexw64 to use mscrt.dll.

Add the hodgepdoge of compiler and linker options to build against the
mscrt.lib/dll provided by the "Windows Driver Development Kit"
(WinDDK). With the WinDDK from Microsoft installed, this allows
building of Screen.mexw64 against mscrt.dll instead of the Microsoft
Visual Studio 2010 C runtime.

Small Plus: Consistent with GStreamer dll's.
Big Minus: Code review shows that the "plus" shouldn't matter given how
we use the GStreamer dll's. We already avoid all potential interactions
with GStreamer which could cause hazards. Building against mscrt.dll
makes it impossible for us to pass environment variables from Matlab to
Screen() or GStreamer, effectively disabling almost all PsychTweak()
functionality and reducing the effectiveness of workarounds for broken
computer clocks.

-> Hopefully this change won't be needed, it is a big net minus!

Here are the things that could cause trouble according to MSDN
documentation if we don't build against mscrt.dll: 1. Passing
environment variables (won't work - they don't show up across dll
boundaries), 2. Passing file handles (which we don't do), 3. Passing
locale settings (which we don't do), 4. malloc()'ing memory on our side
and provide it to GStreamer to own it (which we don't do), 5. free()ing
memory pointers provided by GStreamer (which we don't do). Point 1
explains why the GStreamer debug environment variable settings via
PsychTweak() never had an effect on Windows, but only on OSX and Linux.
Point 2 and 3 we don't do. Point 4 or 5 would cause heap corruption,
but we don't do this. So for all practical means and purposes we should
be just fine using the standard msvc2010 runtime libs as in the past.
Screen for 32/64-Bit Matlab on Windows rebuilt and tested.

32-Bit Screen() just incorporates the locale setting changes from
previous commit.
64-Bit Screen() is linked against mscrt.dll instead of the MS-VisualC
2010 dll's.
-> The latter one is important for testing.
Screen: Make g_thread_init() call conditional on GLib version.

g_thread_init() is only needed up to GLib version < 2.31.0, but
deprecated above. Add a version check macro to avoid compiling it on
GLib >=2.31.0.
Screen/Windows: Add special GStreamer debug code for msvcrt builds.

On Windows + msvcrt builds, no env variables can be passed from Matlab
to Screen+Gstreamer, therefore use a trick to define GST_DEBUG env
variable at Screen verbosity > 20 inside Screen to pass it to
GStreamer. Didn't work either on R2012a, probably because stderr gets
redirected to nirvana. Whatever...
Screen.mexw64 for 64-Bit Matlab on Windows rebuilt and tested.

Another minor candidate for crash testing. Previous builds didn't
improve situation on affected machine out there.
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.
Merge branch 'gstreamerwinexperiment'

* Switch 32-Bit PTB on Windows from OSSBuilds GStreamer to
GStreamer-SDK.
* Compatibility fixes to allow build on Windows against MSCRT.dll.
* Global locale + switching: backup->change->use->restore in 'DrawText'.
* Bug fixes for OpenGL context protection with GStreamer-SDK on
Windows, if clutter plugin support is available in the SDK installation.
WinTabMex: License change, 64-Bit build, improvements by Jason Friedman

* Change license to MIT, remove stale GPL header.
* Add improvements by Jason Friedman: wintab32.dll is now runtime
linked via LoadLibrary(), so no need for anything but the header files
for building. This makes it possible to provide a 64-Bit build of the
file as well.

-> Build the first WinTabMex.mex64 for 64-Bit Matlab on Windows.
-> Rebuild for 32-Bit Matlab on Windows, just for consistency.
Rebuild PsychHID for Windows against latest upstream HIDAPI.

To incorporate latest bug fixes and robustness improvements in the
Windows version of lib HIDAPI from signal11.

-> PsychHID for 32/64-Bit Matlab on Windows rebuilt.
Switch 64-Bit Screen for Windows back to MSVC-2010 runtime instead of MSCRT.

Use of the mscrt.dll didn't help with the 64-Bit crashes observed by
Matthew, neither did it help in debugging, so go back to old and proven
link against Microsoft Visual C 2010 runtime dll's. This is much
simpler to maintain.
Rebuild Screen for Matlab on Windows, now exclusively against GStreamer-SDK.

We no longer support use of OSSBuilds GStreamer runtimes from
GoogleCode for 32-Bit Matlab. Instead we now also require use of the
www.gstreamer.com GStreamer-SDK for both 32-Bit and 64-Bit Matlab on
Windows. This to unify support, maintenance and installation
instructions.

-> Modify C code accordingly to drop OSSBuilds support.
-> Add additional online help text hints in error messages iff
GStreamer fails to load, to give clueless users some extra clues.
-> Screen for 32-Bit and 64-Bit Matlab on Windows rebuilt against
GStreamer SDK.
GStreamer.m: Simplify 'help GStreamer' installation instructions.

Streamline the text. Have unified installation instructions for both
OSX and Windows.