Extract values in HIDParse correctly when compiled in 64-bit (LP64) mode

[nbriggs]

Reworks the conversion of bytes in little-endian order to host order to
operate independently of the sizeof(long) and the byte-order of the host system.
The extracted value is stored as uint32_t as the code already performs casts
to signed/unsigned of varying sizes as appropriate to the context of use.

Closes issue #1015

[nbriggs]

See withdrawn/closed PR #1016 for additional discussion.

[jimklimov]

Thanks, so in this incarnation, does the byte-stream-to-number conversion work reasonably for all host types and word lengths involved?

[nbriggs]

Yes, the new conversion of a little-endian number in the byte stream is independent of word size (32/64 bit) and endian-ness. It doesn't address the bug I raised in issue #1023 which will need some more thought.

[jimklimov]

Just in case - is it also producing numbers as expected for shorter integers (8, 16 bits), in particular with no garbage in uninitialized memory of bytes not touched? Seems all should be OK, but better double-checked than sorry :)

[nbriggs]

Yes, there is no possibility of there being uninitialized bytes in the result as the entire result (pParser->Value) is zeroed before anything is accumulated into it, and the only values subsequently accumulated are the 0, 1, 2, or 4 bytes as specified by the length of the item.

This code is used to parse the report descriptors but not the values that the UPS reports back as its state changes (that's GetValue)