NUT for Windows USB (HID?) drivers may not fully access the hardware by default

[jimklimov]

A specific practical issue to track in context of NUT for Windows effort, so related to some others with broader scope such as #1507 and #1636. It may also relate to packaging e.g. #1485 and older discussions like #1145 and #1050 that touch on issues with latest published NUT v2.6.5 based MSI.

This one is about the hunch that relative failures of USB driver testing seen in development of the Windows branch, such as seeing only device metadata like name/vendor/... but not detailed Report Descriptors with data of interest, were because either further Windows kernel drivers (libusb0.sys, libusbk, etc.) are needed to intercept USB HID devices and/or tap into system's handling of those (as a HID Battery by default), or native means of libusb-1.0 might be utilized (tell it which backend to use).

Looking at https://github.com/libusb/libusb/wiki/Windows#known-restrictions maybe my problems seeing device data stem from not installing libusb-win32 right (or libusbK at all) on the testbed. There should be a kernel level driver to access the device so Windows HID battery support does not preempt a NUT driver, probably.
See also https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/supported-usb-classes

[jimklimov]

Another data point: as investigated in #1690 the Windows OS may by default bind its own driver (e.g. "HID Battery") to the device, so precluding libusb from fully using it; as that issue elaborates in #1690 (comment) comment, the Zadig tool can be used to force the use of a low-level driver we want for specific connections (VID:PID pairs) - possibly until an OS update though, hear-say goes that such overrides may not survive the OS changes if those provide "newer" handlers.

It is also anticipated that completing the NUT for Windows installer quest would provide these VID:PID bindings (written to the OS by the installer with its elevated privileges) same as we have for udev etc. in the POSIX codebase builds.