Screen: Improve Windows-8 compatibility by improved DWM support.

Windows-8 does not allow to disable the DWM 3D desktop compositor
anymore, so our disable calls are ineffective/no-ops. Otoh the bugs in
the DWM's switching logic seem to have been fixed in current Windows-7
and Windows-8: The DWM disables itself for displays which only show a
fullscreen onscreen window, thereby not interfering with our onscreen
windows if they are fullscreen, decorationless, opaque and unoccluded
-- ie., the common case for stimulus presentation.

Try to take this into account:

* Tone down serious error messages if DWM can't be disabled into
informational debug messages on higher verbosity levels. No point
shouting fire if nothing can be done about it on Windows-8 and nothing
needs to be done in the common case.

* Make warning messages about DWM interference more context sensitive:
We can now detect if the DWM is effectively on or off (but not on which
display!): Only print serious warning messages if we can be pretty sure
it negatively affects our stimulus windows, ie., if the DWM is active
on either a single display setup, or if our onscreen window is not a
fullscreen window, as in both cases DWM interference is guaranteed to
affect us. Print more toned down notice messages if the DWM is active
on some display of a multi-display setup, but our window is fullscreen
and in all likelihood not subject to DWM composition, ie., only non-ptb
windows are affected.

* In the single display DWM active case, try to use global info from
DwmGetCompositionTimingInfo() to do timestamping for redirected
onscreen windows. DwmGetCompositionTimingInfo() can only provide global
info, not specific to our windows, as window specific queries seem to
be a) seriously broken in all shipping Windows versions and b) are
officially deprecated as of Windows-8 and will be completely removed in
Windows-9. Therefore we can only use the global information if we're on
a single display setup, where the global information is guaranteed to
be related to our windows. DirectX timestamping seems to deliver
reasonable results, but this still needs to be tested with measurement
equipment.

* The DWM adds (at least) 1 video frame extra delay when active for a
window, so if  a timed Screen('Flip') is requested on a composited
window, subtract 1 refresh duration from the flipwhen deadline
requested by usercode. This compensates for the 1 frame extra lag and
allows proper stimulus onset scheduling at least for cases where the
onset is > 1 refresh cycle in the future. There ain't nothing we can do
for the 1 flip per refresh case though.

* Try to tune the DWM for deterministic minimal jitter composition
timing by restricting the number of video buffers used to the allowable
minimum of 2. This trick is borrowed from the implementation in
Google's ANGLE framework, which is the foundation of WebGL support for
Firefox and Chrome on Windows.

* Delete lots of dead DWM related code from our earlier failed attempts
to coerce the DWM into reasonable behaviour. Not only didn't it work,
it is guaranteed to not work in the future, as relevant scheduling
calls like DwmPresentParameters() have been declared deprecated as of
Windows-8 -- they will be removed from Windows-9 and later.

-> Basic testing on Windows-7 shows reasonable behaviour wrt. warning
messages, swap scheduling, jitter and consistency of swap timestamps in
the composited case, while scheduling and timestamping for fullscreen
windows works perfectly with the old methods even if DWM is forced on,
due to the auto-unredirection of fullscreen windows. This is good.
However, reliability/precision of timestamps for composited windows on
single display setups remains to be tested. Just because they are
self-consistent doesn't mean they are correct. Testing is tbd.

Screen for 32-Bit and 64-Bit Matlab on Windows rebuilt and tested on
Windows-7.
Screen/Windows: Fix the fixes for Windows-8 and DWM.

Turns out, already Window-7 is very fragile timing-wise in
multi-display mode, with and without DWM. Also the DWM does not seem to
auto-disable itself for a fullscreen onscreen window on a multi-display
setup. It does so on effective single-display, ie. real single display,
or dual-display mirror mode, but not in real extended desktop mode on
two displays. Therefore it does affect and completely screw up timing
and timestamping for fullscreen onscreen windows on such a setup.

-> Adapt our warning messages again. What was supposed to be a "don't
worry too much" is now a "be very very scared" message.

-> The only way to get reliable timing is to disable the DWM on a
multi-display setup -- which is impossible on Windows-8 or later, or to
use a single display setup.

Testing with Datapixx showed that:

a) Timing/Timestamping with DWM off is fine: Applies to Windows Vista/7.
b) Timing/Timestamping with DWM on, but auto-disabled is fine on single
display setups under Windows-8 -- probably, as this was only simulated
on Windows-7, not tested on a real Win-8 system.

c) DWM active on single display setup works ok most of the time via use
of DWM internal timestamping instead of our standard timestamping.
However, there are occassional glitches, where the DWM claims a flip
was delayed when it actually wasn't delayed according to Datapixx.

Screen for 32-Bit and 64-Bit Matlab for MS-Windows rebuilt and tested
with DataPixx timestamping. VBLSyncTest improved with basic/quick
Datapixx timestamping option.
PlayMoviesDemo: Add some Elon Musk talk to "cool" videos playlist.

Interesting and entertaining info about space travel, electric cars and
solar power.

Also auto-create GStreamer video .cache directory in ~/.cache if it
doesn't exist yet, so prebuffering of web video works.
MouseTraceDemo3: Detail improvements.

* Hide system cursor pointers and draw our own cursors.
  This avoids flicker due to software cursor rendering.

* Related: Use offscreen window as drawing canvas, to
  make our own cursor rendering nice.