Screen/Linux: DRI3/Present bug workaround I - glXWaitForSbcOML()

As of Mesa 10.3.3, Mesa's DRI3/Present implementation of
glXWaitForSbcOML() is broken in that it doesn't treat the
targetSbc=0 special case properly. Instead of blocking until
all pending bufferswaps have completed, it just falls through
and returns whatever last (ust,msc,sbc) triplet comes along its
way. This caused various disastrous failures in PTB's swap
scheduling and timestamping.

Workaround this by:

1. Implementing PsychOSFlipWindowBuffers() as a call into
   PsychOSScheduleFlipWindowBuffers() with equivalent swap
   timing, by use of targetSBC=1, divisor=remainder=0. This
   way the windowRecords->swaptargetSBC gets updated with the
   expected SBC of swap completion.

2. Using that value in PsychOSGetSwapCompletionTimestamp() in
   the targetSBC=0 case, so glXWaitForSbcOML() gets called with
   a specific non-zero targetSBC and mostly does its job.

-> This should have no negative impact on performance or reliability/
   precision compared to the old implementation wrt. both DRI3/Present
   or good old DRI2, so we can keep this unconditionally enabled.

-> This fixes swap scheduling and swap timestamping when tested
   under XOrg 1.16.2 + mk-fixes with standard Mesa 10.3.0 under
   nouveau-ddx master on nv-50 with 'exa' backend on a Linux 3.17
   kernel with rendernodes enabled and thereby DRI3/Present in use,
   both for non-composited and composited setup, fullscreen, transparent
   and windowed. More tests (glamor, intel-ddx sna/uxa/glamor) pending.

-> There are more bugs in Mesa, which are currently worked around:
   Scheduling a glXSwapBuffersMscOML() swap with targetMSC=0 causes
   the swap to hang -- the request never reaches the server! Needs
   investigation, likely another Mesa bug.

-> Potential race between glXGetSyncValuesOML/glXWaitForMscOML() and
   glXWaitForSbcOML() under DRI3/Present: Mesa uses same ust,msc
   vars for all those functions, so calls to the msc wait/query functions
   can change the (ust,msc) results for WaitForSbc, e.g., if following
   scenario happens:

   1. Schedule bufferswap for some targetSBC.
   2. Swap completes -> PresentCompleteNotify Event -> Mesa stores msc,ust.
   3. Wait a refresh cycle or more, so msc,ust increment.
   4. glXGetSyncValues() query to server updates the msc,ust of
      swap completion from step 2 with msc, ust of last vblank.
   5. glXWaitForSBC for targetSBC returns immediately due to step 2
      which already happened multiple refresh cycles in the past. Returns
      the msc,ust of step 4. instead of from step 2, as old values have
      been overwritten!!

   Rereading the spec, one could interpret its wording in a way that this
   is actually compliant behaviour, so technically this wouldn't be a
   DRI3/Present bug in Mesa. However even if this should be correct behaviour
   on paper it would be completely non-sensical and fragile behaviour for any
   practical use of the spec. Needs discussion on xorg-devel/mesa-devel to see.
   Long-term might be better to replace our use of WaitForSBC with sole use of
   the swap events extension to avoid such pitfalls...
Screen/Linux: DRI3/Present (bug?) workaround II - Triple-buffering / n-buffering.

Mesa n-buffers its OpenGL backbuffers under DRI3/Present, with values
of n that can dynamically change depending on if bufferswaps currently
happen via CopySwaps or Pageflips, and if vsync is on or off, aka
swapinterval is non-zero or zero. These are performance optimizations
to achieve higher/more stable framerates for apps which want that.

The implementation is consistent with precise swap scheduling and
swap completion timestamping, aka triple-buffering done right :)

However, this means we can no longer make the assumption that
OpenGL bufferswaps performed via pageflipping actually retain
the contents of post-swap backbuffers as with pure double-buffering
and fixed buffers. Instead post-swap we may get a new uninitialized
backbuffer with undefined pixelcontent any time, depending on load
and other factors. This means that our video refresh calibration
and startup sync tests now need to draw the startup logo before every
bufferswap, otherwise users would see a lot of pixeltrash.

-> Add neccessary PsychDrawSplash() calls to calibration/testing
   loop.

-> So far so good. However the fact that omitting these calls not
   only causes pixeltrash at startup, but also totally weird tearing/
   unsynchronized rendering artifacts throughout a whole following
   work session - rendering corruption wherever you look - hints to
   some potential bug in Mesa 10.3.0's n-buffer management. One of
   these bugs nobody except us psycho-weirdo hits, because only we
   do strange things like sequences of bufferswaps without any
   rendering between bufferswaps. -> Needs investigation into the
   mechanism and root cause of this.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.