Make all mex files reentrant - But only apply to test build of Screen for now.

Make it possible for a PTB mex file / module to call itself
recursively, e.g., Screen() as part of imaging pipeline processing
calling into M-Functions or the interpreter which themselves call
Screen(), e.g., to query some properties.

So far this was impossible because some of the state in
PsychScriptingGlue, mostly for communicating with the scripting
environment, was global state to the file, stored on the heap or bss,
not on the function call stack. A function calling itself recursively
would have overwritten its own scripting glue state from a lower
recursion level and caused bad data corruption and trouble.

Now we implement our own mini-stack for those few variables (nlhs,
nrhs, plhs, pros, etc.) which need to be global to the file and not
just local to mexFunction(), with our own stack pointer variable
‘recLevel’ to index. recLevel is incremented and checked during entry
to the main dispatch mexFunction, decremented during regular exit from
mexFunction at return to the environment, as well as during error exits
before mexErrorMsgTxt(). Debugging output can be enabled via
setenv(‘PSYCH_RECURSION_DEBUG’,’1’); before first invocation of a
module. The stack depths and thereby max recursion level is #define’d
as MAX_RECURSIONLEVEL to a maximum of 5. I can’t think of any situation
where we’d need more than 2 or maybe 3 levels, so this should be plenty.

Tested via Screen’s imaging pipeline, both for regular completion and
error cases, both with and without async flips. Seems to perform
correctly.

-> Screen for 64-Bit Octave and Matlab on OSX rebuilt and tested. Works
on Octave and Matlab.
-> This currently has no benefit for modules other than Screen(),
because only Screen() can possibly call itself via its imaging pipeline.
-> Currently none of PTB’s code makes use of this feature, but it would
have been beneficial a couple of times in the past to simplify code or
make it more robust.