GetEchoString, GetKbChar: Fix for Linux.

Need to leave text user alpha blend setting disabled on Linux, as
opposed to Windows and OSX.

Also add recognition of Backspace key as character delete key, otherwise
we wouldn't have any character delete key on many Apple keyboards.
libptbdrawtext_ftgl: Workaround typo in public api.
Screen/Linux: Implement our own display locking instead of XLib's

This is mostly to protect access to XLib functions (and also GLX functions, as they
are using XLib/X11 as transport), but could also be used to protect access to other
backend libraries for display configuration and stimulus onset control.

We use this as we don't want to rely on XLib's builtin locking and thread-safety.
Why? Because XLib's multi-threading protection must be initialized at application
startup time *before any other XLib calls* via a call to XInitThreads(), and we
do not have any control if or when that XInitThreads() call happens, so it is better
to not rely on Octave, Matlab or other future hosting environments doing the right
thing. Instead we implement our own locking around potentially racy XLib calls.

XLib itself is reentrant, but concurrent access by multiple threads to the same xdisplay
connection handle, and thereby to the same x-windows connection queue is not safe.

We use one shared xdisplay handle for all onscreen windows and screens, across all of
Screen's threads (main thread and async flipper/frame-sequential stereo threads). We
need to use one shared handle because otherwise OpenGL context resource sharing and the
OML_sync_control timing and timestamping functions won't work properly. Therefore we
must lock-protect all calls by all threads to XLib. N.b. PsychHID uses its own private
xdisplay handles for its KbQueue thread and KbCheck, but those handles are really only
used exclusively by one respective thread, so no need to worry about locking PsychHID's
ones.

For now we only maintain a global lock and will extend this into finer-grained locking if
neccessary. Using XCB would be another option, but that would be a huge rewrite with
rather sparse documentation available...

One small problem: GetMouse() is still implemented via Screen('GetMouseHelper') on
the x-display connection of Screen. This means that a very fast polling GetMouse could
in theory cause lock contention on the lock used by async flipper threads and possibly
delay a bufferswap if oml-sync-control is not in use, e.g., on the proprietary Nvidia
and AMD binary blob graphics drivers. Hard to say how serious this problem really
can be in practice.

-> Screen.mex for 64-Bit Octave on Linux rebuilt and lightly tested.
-> Old XInitThreads() call in Screen disabled.
-> Small optimization in GetMouse.m to avoid one redundant call.