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 :)

See following Mesa commits for details:

Mesa 10.3:   3fbd1b0cb576b46ac8df2697cb388db78f48012d
Mesa master: f7a355556ef5fe23056299a77414f9ad8b5e5a1d

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.
Merge branch 'master' of https://github.com/kleinerm/Psychtoolbox-3