Dataset compatibility check should take operating system into account

[daniel-j-h]

Every now and again (ref. 1) users try to pre-process on Linux and then move the files to Windows for routing or the other way around. This won't work since the .osrm.* files are more or less byte dumps for internal structures: these can and will change across compilers, stdlibs but especially across Linux and Windows where all hope is lost.

Our data compatibility check should take the operating system the data was generated on into account and compare it with the operating system currently running on. The fingerprint needs to store an enum value based on the operating system which we can then dump out. Note: the fingerprint's magic number needs to change implementing this feature, since fingerprints will be incompatible.

[TheMarex]

Actually I think we should investigate why this leads to problems, because I don't think we actually don't write anything stdlib related to disk. It should all be structs we defined ourselves. Difference it encoding would indicate we rely on some sort of compiler-specific padding/packing.

I'm not sure how we could ensure this via CI however. That would mean we need Travis to produce datasets to test on the AppVayor builds.

[daniel-j-h]

Compiler specific bitfield representations, padding, and offsets come to mind. We're on thin ice here anyway not sure what needs to be done to make byte-wise dumps portable across platforms.