fix: decoder now handle bad encoded fit file when size < basetype.Size

[muktihari]

There is a case where a FIT file generated from a well-known brand contains fieldDef's Size which less than fieldDef's Basetype.Size(): Size is 1 byte but the type is uint32 which should have been 4 bytes. This cause panic in our current implementation since the binary unmarshaler will try to unmarshal 4 bytes but we got only 1 byte in []byte slice, index out of bound.

Actually, we do not want to support bad encoded FIT file as there might be too many cases to handle and adding complexity to our code. However, this bug causes panic in our FIT SDK so we need to take a measurement and gracefully handle such cases.

Returning an error is one of the options, but then we can't get the FIT file contents at all, so let's make a simple workaround to handle that so we could retrieve the contents as much as we can and just write a log message when the Decoder found such cases so user known that the data they are receiving might be changed due to the value type casting.

[muktihari]

ref:

• Coros Pace 2 Activity Issues GoldenCheetah/GoldenCheetah#3645
• Coros fit file parsing: validating Event failed tormoder/fit#78
• warn and fall back to byte encoding, rather than fail, in the case of a mismatched field size dtcooper/python-fitparse#116