Compression error with API and point type 6

[abellgithub]

Sometimes laszip will not properly compress type 6 points if legacy flag fields aren't populated. The data in these fields are already populated in extended_classification_flags, and therefore should not need to be populated when writing extended point types (point format 6 or higher). Certainly bad data shouldn't be written. The following command generates output that can't be read by lasinfo:

./example wontcompress3.las wontcompress3.laz

This issue has been noted on OSX and Ubuntu.

Github won't let me attach the files directly. Use the following link to obtain the example program and data:

https://drive.google.com/open?id=1XG0Eunrt20HO9WvbQ9DK8uLe5859WZ88

[rapidlasso]

This bug is result of the (implicit) expectation that the three legacy flags and the three corresponding flags in the extended_flags field are identical. Violating this expectation was causing encoder and decoder to get into different internal compression context states which can result in corrupt LAZ files if flags are set in an inopportune moment. This commit makes the dynamic linked library API validate that this assumption is met and fail otherwise. This is an immediate fix to prevent the generation of corrupt LAZ files in the future. A future version of the DLL may handle this more cleverly: 2a36ee0