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.