Decode 3D texture coordinates in upgrade

[javagl]

This replaces the draft at #146 with a ... somewhat cleaned-up version that focusses only at the decoding part:

• glTF 1.0 (in B3DM or I3DM) could contain 3D (!) texture coordinates stored as SHORT
• in glTF 1.0, these had been decoded in the shader (that was part of glTF 1.0)
• When upgrading glTF 1.0 to glTF 2.0 with gltf-pipeline, then the 3D texture coordinates are transferred to the glTF 2.0
• This caused an invalid asset (e.g. with rendering errors in CesiumJS)

The exact encoding of the texture coordinates is not yet clear. It just seems to be "one (arbitrary) way" of not storing the VEC2/FLOAT (2 * 4 = 8 bytes), but instead, storing VEC3/SHORT (3 * 2 = 6 bytes). At the time of writing this, one glTF file that has this structure is stored publicly at https://assets.agi.com/models/f-16_falcon.gltf (unclear licensing, therefore, not replicated here). In this asset, the decoding is done like this:

const float uvMultiplier = 0.0000305185; // 1/32767
v_texcoord0 = a_texcoord0.xy * uvMultiplier * (a_texcoord0.z+32767.0);

This PR implements the decoding of VEC3/SHORT (or VEC3/BYTE) texture coordinates into VEC2/FLOAT texture coordinates. From a quick test with a B3DM file that contained the glTF data given above, the result can be rendered in CesiumJS.

Note: There seems to be no agreed-upon name for this compression technique or its details. Therefore, the implementation here can only be a best-effort guess. But it has little or no negative impact: When there are 3D texture coordinates, then the asset is invalid. We'll try to decode them into a valid form. When it works, everything is fine. Otherwise, the result is still invalid 🤷‍♂️ .

(I'd like to add a spec/unit test case. But I'd first have to create such old/invalid data, which would involve some manual work. Not sure whether this is worth the effort...)