Screen/Linux: mexLock() Screen() into memory if running on Mesa OpenGL

Turns out Mesa, at least as of 10.1, as shipped in Ubuntu 14.04-LTS,
has a bug which causes it to crash on a "clear Screen" -> Reload Screen
cycle.

On first call in a session to glXGetProcAddress('glfoo') to get the
entry point to gl function glfoo(), if the stub for this function
needs to get dynamically generated, Mesa will do so, but it will
setup a persistent pointer to the name string 'glfoo' passed to the
glXGetProcAddress() function. It will use the callers memory space
to cache the name string, instead of creating its own private copy!

For us this means that if Screen() calls glewInit() to setup gl
entry point bindings, Mesa will have pointers into the inside of
Screen! If the user 'clear Screen' unloads the Screen.mex file,
then reload it - usually to a different address in the address space
due to relocations or maybe address space layout randomization -
Mesa (specifically libglapi.so) will have dangling pointers to
unallocated memory. Next time somebody (e.g., reloaded Screen())
calls glXGetProcAddress(), libglapi will deref these invalid
pointers and crash!

As various bits of Octave and Matlab also use OpenGL and therefore
hold references to libOpenGL / libglapi, both libraries won't get
unloaded / reloaded when our Screen.mex file gets unloaded/reloaded,
therefore the dangling pointers won't get reinitialized properly.

The only real fix for this crasher is to fix Mesa with a trivial
one-liner bugfix. However, until that is done, we need a workaround.

Our workaround is to mexLock() Screen() into memory as soon as
"Mesa" is detected as underlying OpenGL library, so we can't get
clear'ed out of memory until session termination.

This can be prevented via setenv('PSYCH_DONT_LOCK_SCREEN','1'); and
won't happen at all on non-Mesa OpenGL implementations.

-> 'clear Screen' / 'clear mex' / 'clear all' won't clear Screen,
   with all the annoying inconvenience this causes to some users and
   Mk specifically during development. Better than crashing tough.

-> Hashtag: SoftwareSucks.
Screen/Linux: Add gcc pragma to suppress XKeyCodetoKeysym deprecation warning.
Screen/GStreamer: Change handling of pipeline bus messages.

Turns out our old method of receiving/handling messages on the
GStreamer GstPipeline message bus doesn't work on Octave 3.8 under
Linux if Octave's QT based GUI is active :(

The Qt toolkit on Linux - and thereby Octave on Linux GUI - uses
glib's event loops internally for some GUI event processing. We
also used glib's default event loop to process/dispatch bus
messages and this caused cross talk between Octave GUI and our
GStreamer backend - Octave GUI ate our events, so we never received
them. This caused failure to loop videos during playback because
we didn't get the EOS messages needed to trigger a rewind. It also
made error handling useless, because we couldn't get the error and
warning message events.

Now all our GStreamer backends (video playback, video capture/recording,
movie writing) implement a new strategy in their PsychGSProcessContext()
methods. Direct polling of the bus and direct dequeueing/dispatch without
GLib's event loops. Old code is still there as disabled alternative.

-> Works now fine under Linux with Octave GUI/CLI and Matlab GUI/CLI.
-> Needs retesting on OSX and Windows. If this doesn't work i will sob
   uncontrollably. How painful can this get??

-> Screen for 64-Bit Octave/Matlab on Linux rebuilt and tested.
-> Test on other platforms pending.

HashTag: CanThisReleaseCycleSuckEvenMore?