Implement GetChar() et al. on some non-Linux setups via KbQueues.

Octave and matlab -nojvm on OS/X, as well as matlab -nojvm
on Windows and any Matlab on Windows Vista or later have trouble
with the current GetChar implementation, iow. GetChar sucks on them:

1. "matlab -nojvm" and Octave in general don't support Java based
   GetChar. The low-level Unix style fallback in Linux works fine
   in those cases, providing reliable GetChar operation. The same
   Unix fallback on OSX fails miserably, apparently due to the way
   the windowing system dispatches key events on OSX, as does the
   MS-Windows low-level equivalent.

2. On Windows Vista and later, the graphics systems keyboard focus
   policy interferes and makes even Java based GetChar unuseable
   in conjunction with Screen() windows.

-> We need a new solution for those combos.

This reimplements ListenChar, FlushEvents, CharAvail and GetChar
on top of PsychHID keyboard queues, as those are in principle not
affected by the mess above. Those functions create and start a
keyboard queue for the default keyboard device, then use KbEventBuffer
mechanism to collect and dequeue key presses, cooked to ASCII codes.

On OS/X this will restrict GetChar et al. to the default keyboard.
On Windows, we can only access one keyboard, which is a virtual
system keyboard - the union of all real connected keyboards. But this
is what we ideally want, so one Windows design flaw turns into an
advantage for us at least once ;)

The problem here is that we only have one queue per keyboard, so
the queue handling the default keyboard can be either used by
GetChar et al., or by regular usercode via the KbQueueXXX and
KbEventXXX functions. A new locking mechanism arbitrates between
both on a first-come-first-served bases.

This commit is incomplete, as it needs more extensions to PsychHID,
and especially to PsychHID on OSX. But it implements the support
code in the M-Files and the arbitration.

PsychHID needs to somehow return a count of valid keypresses,
not only a total count, otherwise we can't implement CharAvail()
properly.

The keycode to ASCII code mapping on OSX is currently broken.

This also adds a new helper function IsVista() to check if the
system is a MS-Windows Vista or later system.
PsychHID: Add ability to only count mappable keystrokes in event buffer.

This is to make the KbQueue based GetChar() / CharAvail()
implementation work.
The 'KbQueueFlush' function now supports a flushType setting of & 4. If
used, the function will not return the full count of queued events for
a KbEvent buffer, but only the count of key down events with a
successfully mapped CookedKey field, ie. translated to valid
ASCII/Unicode character key strokes. This is basically what CharAvail()
needs to function properly.

PsychHID for MS-Windows 32/64-Bit Matlab rebuilt and tested.
PsychHID for OSX 64-Bit rebuilt for basic testing, but char mapping
doesn't yet work.
Finalize M-File portion of new GetChar implementation.

This one is successfully tested on MS-Windows-7 with 32/64-Bit Matlab
with JVM enabled. That combo does use the new implementation, so it
works with Win-Vista et al. sick way of window keyboard focus handling.
Additionally it uses the old Java based GetChar in parallel, so
character suppression via ListenChar(2) works.

Minus possible bugs, the M-File part should be good to go.
GetChar et al.: Add quirk handling for Octave on OSX.

Needs the KbQueueCreate->Release->Create quirk to work on Octave on
OSX, just as when using KbQueueCreate directly.
PsychHID/OSX: Implement proper keycode -> CookedKey mapping.

This finally makes the event.CookedKey field of events retrieved from
KbQueues event buffers meaningful. Now keycodes are properly mapped to
Unicode/ASCII characters, for consumption by GetChar.m. The
implementation handles the ALT and SHIFT modifier keys properly,
ignores other modifiers. This enables our GetChar() fallback for Octave
and matlab -nojvm on OSX properly. However, 32-Bit Matlab in -nojvm
mode is not supported, as the minimum OS version for this is 10.5
Leopard, which is only required by 64-Bit PTB on OSX, so we have to
exclude the legacy 32-Bit variant.

PsychHID for 64-Bit Octave and Matlab on OSX rebuilt and tested.
PsychHID: Allow query of deviceIndex of default kbQueue keyboard.

PsychHID('Devices', -1); returns the deviceIndex of the keyboard device
that gets used as default keyboard device for kbQueues. Needed by new
GetChar() implementation based on KbQueues. Add detection code to OSX
version, which was so far missing.

Tested on OSX and Linux so far.
Screen('GetMouseHelper'): Improve low-level tty magic code on Unix.

On Linux and OSX, this code allows successfull suppression of keystroke
input to Octave or matlab -nojvm, ie., when running in a terminal
without Java based GUI.
This works with some low-level Unix layer tty magic. Basically it
disables character echo'ing on the controlling tty and detaches stdin
from the tty, reattaches it temporarily to /dev/zero for "no input".
This implements ListenChar(2). On ListenChar (<2), this is undone by
reattaching stdin to the controlling tty and restoring echo state of
the terminal. If character collection via tty is requested, still
canonical input processing and input buffering is disabled.

Character suppression is only available on Linux and OSX in combination
with the keyboard queue GetChar method. It won't work on MS-Windows +
matlab -nojvm as the tty magic is non-portable to Windows.

Character collection via tty+stdin is only available as a last-resort
fallback path on Linux if the default keyboards keyboard queue is
already in use by usercode. It never worked reliably on OSX or Windows.

Remaining problem: Character suppression does not get disabled on error
or return to Matlab/Octave command prompt or input, leaving a dead
keyboard behind, with the need to kill octave (Matlab kills itself on
return to input in this case, probably due to EOF read or stdin stream
error when reading from /dev/zero).

Tested on OSX and Linux with Octave and matlab -nojvm.
GetCharTest: Test timestamping as well at the end.

Works now on most setups, so test it.
GetChar et al.: Fix bugs and glitches in M-Files.

To make it actually work. Scheme for the whole thing:

1. On Octave, or matlab -nojvm: Use Keyboard queues for GetChar by
default. On Linux, fallback to tty+stdin method if queue occupied. On
Linux and OSX suppress characters via tty magic, on Windows (matlab
-nojvm) let it spill.

2. With Matlab in Java GUI mode: Use Java-GetChar on all systems for
character suppression. Use Java-GetChar on OSX and Linux and WindowsXP.
Use keyboard queue on Windows Vista and later, as Java is unreliable
there.

Use of the default keyboards keyboard queue and GetChar et al. in
kb-queue mode is mutually exclusive. Locking takes care of this. On OSX
there's only one kb-queue, so any use of kb-queues is mutex. with
Octave or matlab -nojvm + GetChar.

The best strategy is still to generally avoid GetChar and friends and
use Keyboard queues KbXXX etc. directly if possible.
Disable GetChar et al. on 32-Bit matlab -nojvm on OSX.

Due to lack of support of keycode mapping in 32-Bit PsychHID for OSX,
we can't support kbqueue based GetChar() in 32-Bit Matlab on OSX, so
-nojvm mode is no-go. Jave based GetChar continues to work.

Check for this combo and error() out if somebody tries.
Screen: Disable stdin+tty magic keystroke suppression on error/sca et al.

Disable tty keyboard suppression (if enabled) at
Screen('CloseAll')/error/clear etc. This will also revert to normal
mode if any other mex files detects an error, as they all call sca;
Same goes for try-catch-sca error handling.

Tested on OSX for now.
PsychHID: Fix KbQueues for Octave on OSX.

Finally the culprit of the unreliable KbQueueCreate behaviour on Octave
+ OSX seems to be found and fixed. Queue creation was often unreliable
and subject to race conditions in thread startup. Apparently getting
the CFRunLoopRef via CFRunLoopGetCurrent() instead of
GetCFRunLoopFromEventLoop(GetCurrentEventLoop()) fixes it. The latter
only worked with Matlab. Now this is untested on 32-Bit Matlab + OSX,
could be we need to introduce it there again in case the new modus
operandi makes trouble with legacy code.

Testing under OSX with 64-Bit Matlab with jvm and matlab -nojvm and
64-Bit octave  now shows reliable operation. PsychHID 64-Bit for Matlab
and Octave rebuilt.

Also remove all workarounds for this problem from the relevant M-Files
ListenChar, FlushEvents, GetChar, CharAvail and KbQueueCreate.

Let's hope this really fixes it.
Improve error reporting for mutex between GetChar et al. and KbQueues.

Only report the mutex warning if that is the culprit for KbQueue
failure, not if the failure is simply due to a missing KbQueueCreate()
call.

We don't want to confuse our confused users more than neccessary with
misleading error messages.
PsychHID/OSX: Add CTRL+C handling in KbQueue-Thread.

The thread now detects the CTRL+C combo and responds to it (on Octave)
by calling Screen()'s ConsoleInputHelper() function to reenable
keyboard input to Octave. Ie., this implements an undo for
ListenChar(2) on Octave by restoring the original stdin + controlling
tty. The hack doesn't work on matlab -nojvm, as we can't get a dlsym()
function pointer into Screen(). Apparently Matlab uses a different
dynamic linking method when loading its mex files. Anyway, matlab
-nojvm is seldomly used on OSX, so this is probably not a big issue,
whereas the crucial support for Octave works now.

So far tested on 64-Bit Matlab and Octave on OSX. This is not supported
on 32-Bit legacy Matlab, but neither are keyboard queue based GetChar,
so no problem.
Screen/PsychHID: One approach to CTRL+C propagation on Linux+Matlab

This again uses cross-plugin calls from PsychHID to Screen's
ConsoleInputHelper(). However, on Linux we needed to add logic to
Screen(), so we can export its symbols. The trick is to use the Unix -
only function dladd(), so Screen can detect the full path to its own
mex file, then to re dlopen() itself without reloading itself, and
changing its dynamic link flags in the process, then to dlclose() its
new reference to itself. This works on Linux, with the -D_GNU_SOURCE
flag set at compile time, and OSX without need for a compile flag. Why
do we need this on Linux, but not OSX?
Because Octave does not specify if symbols in loaded mex files should
be public to the whole process, or private to the loaded library. The
Linux dlopen() function defaults to RTLD_LOCAL for private symbols by
default, whereas OSX dlopen() defaults to RTLD_GLOBAL for public
symbols by default.

Now this trick works nicely with Octave, but not with Matlab. The
reason for that is that Matlab's mex file build process uses a linker
export file which restricts exported functions to only one public
function "mexFunction()". This linker export file overrides whatever we
do in the C-Code. The only way to fix this is to edit the Matlab linker
export file for each version of Matlab and each architecture on each
build machine. This works, but is a maintenance hazard!

For this reason, this approach of disabling ListenChar(2) via
cross-calls to ConsoleInputHelper() inside Screen() in octave or matlab
-nojvm is not the way to go. The next commit will simply transplant the
ConsoleInputHelper() function into PsychHID, so PsychHID's keyboard
thread can directly call the function without need for cross-module
calls.

We still document the approach with these commits, and at least leave
the reloading logic in Screen() intact, as these tricks may become
useful for some other future PTB features.
Implement CTRL+C handling for ListenChar(0) on Linux and OSX

The ConsoleInputHelper code has moved to PsychHID, so the kbqueue
thread can directly dispatch a CTRL+C to to it on OSX and Linux. This
removes the need for cross-module function calls and linker magic.
Screen() / PsychHID cleaned up accordingly, as well as ListenChar.m

The new PsychHID('KeyboardHelper') subfunction wraps
ConsoleInputHelper().

Screen, PsychHID, IOPort for MS-Windows 32/64-Bit Matlab and Linux
32/64-Bit Matlab/Octave, as well as Screen/PsychHID for OSX 64-Bit
Octave and 64/32-Bit Matlab rebuilt and tested.

The new GetChar et al. now works ok. Still problematic: CTRL+C does not
get properly dispatched on OSX Octave/matlab -nojvm with an onscreen
window open, because the window blocks our terminals input, and the
terminal doesn't have input focus.
PsychHID: Tiny code cleanup and fix double CTRL+C on OSX.

Remove some dead #include, fix some whitespace.
Make sure CTRL+C handling is only triggered on OSX on 'C' key press,
not also on release. Fixes dual-issue of CTRL+C.
PsychHID/OSX: Backup commit for new CTRL+C handling on OSX.

Another approach, which looks promising at least for Octave:
1. Instead of attaching /dev/zero, attach a Unix pipe() to the
runtime's stdin.
2. Runtime reads from pipe aka stdin, kbqueue thread writes to pipe,
can inject detected keystroke characters into runtime while it is in
interactive mode.
3. Inject CTRL+C via a kill SIGINT signal.

-> Matlab and Octave respond to CTRL+C properly with script abort and
return to command prompt. Matlab does not terminate anymore.
-> Octave receive keyboard input, Matlab apparently doesn't.

This is a backup commit before cleanup and refinement.
Screen/OSX: Try to restore keyboard focus of runtime on 64-Bit runtimes.

Closing a fullscreen onscreen window at the end of a session while
using Octave or matlab -nojvm on OSX often leaves the terminal window
without keyboard focus - how inconvinient. Try to restore keyboard
focus on 64-Bit Octave and Matlab with black magic: We enumerate all
windows, match them wrt. to window and parent process name as well as
stacking order, to find the best candidate for the Octave/Matlab
command window. We extract its associated process id pid and use Cocoa
to activate windows of that process. This typically brings the proper
window to the front and gives it keyboard focus. Sometimes it fails,
only the brainiacs at Apple know why.

Unsupported on legacy 32-Bit Matlab on OSX. Not needed on less
brain-damaged systems like Linux or OSX.

Screen for 64-Bit Octave/Matlab for OSX rebuilt and tested.
PsychHID: Disable tty magic on clear PsychHID.

To leave runtime in a well-defined state.