Handle GLB BIN padding bytes

[javagl]

In a binary glTF, the first buffer refers to the BIN chunk data. According to the glTF specification ...

The byte length of the BIN chunk MAY be up to 3 bytes bigger than JSON-defined buffer.byteLength value to satisfy GLB padding requirements.

This was checked a bit too strictly in the GltfReader: It reported any BIN chunk that was more than 3 bytes larger than the buffer as an ERROR, and did not return a proper model.

This PR changes the behavior to

• Report an ERROR when the buffer size is larger than the BIN chunk size
• Report a WARNING when the buffer size is more than 3 bytes smaller than the BIN chunk size, but still return a valid model
• Report nothing otherwise (because the buffer being up to 3 bytes smaller than the BIN is valid according to the specification)

A test case has been added with a GLB that contains a buffer with a length of 44 bytes and a BIN chunk with a length of 48. This could not be loaded before this PR. Now it (only) causes a warning

The size of the first buffer in the JSON chunk is 44, which is more than 3 bytes smaller than the size of the GLB binary chunk (48)

but still returns a valid model.

---

A bit more context:

When GLB data is part of a B3DM, then there are stricter alignment requirements. And until a recent clarification, the specification required the GLB to end at an 8-byte boundary, even though this requirement does not apply to the GLB itself, but to the tile data. The previous wording had caused several tools to just append padding bytes to the GLB BIN chunk, leading to many B3DMs containing GLB that caused the validation message

BUFFER_GLB_CHUNK_TOO_BIG: "GLB-stored BIN chunk contains 4 extra padding byte(s)."

and that could not be read by cesium-native due to the strict size check.

[lilleyse]

@javagl can you update CHANGES.md? Then this should be good to merge.

[lilleyse]

Thanks @javagl