fix: adding a mechanism to check for presence of m-values during parsing

[vojtatom]

Fixing an issue when geometry with type XYZM didn't have the M values provided, in the shp file, since in those cases the M values are optional per spec file.

Resolving #13.

The solution checks for a record length during parsing because I’ve found no other reliable way to determine the presence of the M-values. There’s no other reliable indication of the presence of optional M-values on the file level.

Other solutions considered parsing ranges from the file header, but that proved unreliable. The added example testing file doesn’t contain M-values, the shape type is XYZM, but the header still doesn’t contain the expected NaN values at the M-value range (header bytes 84, 92), it contains values (0, 0). That could denote a presence of the M-value, just with 0 zero values.

[vojtatom]

@wewindy, please could you check whether this works for you?