WebHID: Windows preparsed-data fields decoded from the wrong layout

The issue descriptor has two top-level Application collections: Consumer Control and Phone. Linux reported type: 1 with logical ranges 0..652 and 0..191. Windows reported type: 0 and reversed-looking logical limits because Chromium interpreted Windows HID preparsed data with an incomplete channel descriptor layout.

CL 8352866 handles Windows button items using their distinct union layout and reads the collection type from the link collection node.

Prebuilt Windows installer containing the fix from CL 8352866:

• mini_installer.exe (205 MB)
• MD5: 312edb624b9eaefe5594c1cd21863c91

05 0c 09 01 a1 01 85 03 15 00 26 8c 02 19 00 2a 8c 02 75 10 95 02 81 00 c0
05 0b 09 01 a1 01 85 05 15 00 26 bf 00 19 00 2a bf 00 75 10 95 02 81 00 c0

• Consumer Control Application collection, report ID 3, logical range 0..652.
• Telephony Phone Application collection, report ID 5, logical range 0..191.

Windows exposes parsed HID metadata as internal preparsed data. In HIDP_CHANNEL_DESC, logical min/max fields are at different offsets for button items than for data items. The old Chromium structure read button items as data items. The CL adds the button layout and keeps the parsed top-level collection type instead of defaulting to zero.