Fix for bad DMX USB plug-in timing on Windows

[basilhussain]

This pull request fixes bad DMX timing from the DMX USB plug-in when running on Windows. See issue #1656 for discussion.

The following changes are implemented:

• Requests a system timer resolution of (by default) 1 millisecond during instantiation of any class that inherits from DMXUSBWidget. Closes that request during destruction.
• Allows a different timer resolution value to be requested via use of dmxusb/windowstimerresolution registry key setting. (I don't imagine much use for this, but added it just in case.)
• On Windows 11, during application initialisation, requests that the system timer resolution not be throttled whenever the app is minimised, occluded, etc.

This will resolve the following problems:

• Inconsistent DMX frame intervals for all DMX USB plug-in variants.
• For the Enttec Open DMX USB in particular:
  • System timer accuracy should now always be legitimately "Good".
  • Avoids high CPU usage (caused by busy-wait being used to wait for frame interval) when system timer accuracy was detected as "Bad".
  • Avoids terrible break/MAB timing and cut-off frames when timer accuracy was bad, but mistakenly detected as "Good".
• Any other plug-in variant that attempts to perform system timer accuracy detection should also now get proper "Good" results.
• On Windows 11, minimising or occluding the app window will not lead to degraded timing.

I have tested these changes on Windows 11, Windows 10, and Windows 7.

Some other notes:

• I'm not experienced with CMake, and so I don't really understand what PUBLIC or PRIVATE within target_link_libraries in the CMakeLists.txt specifies, what the difference is, or if it even matters. Looking at other areas where winmm is linked, there is no consistent usage - both are used.
• Casting of the return value from the call to GetProcAddress was triggering a compilation error, but I am puzzled as to why only for this code and not for any other usage of GetProcAddress in other code elsewhere (e.g. peperoni, hid plug-ins). Are the compilation error/warning options different for the dmxusb module? I had to add a #pragma to ignore the error, because the cast is absolutely necessary.

[yestalgia]

This could be ground-breaking, thank you for taking the time.

Other Windows OpenDMX issue for reference: #1666

[coveralls]

coverage: 31.497%. remained the same
when pulling c9b1131 on basilhussain:dmx-timing
into bfd497a on mcallegari:master.