Add KHR_texture_basisu parsing

[abwood]

Adds support for https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_texture_basisu

In the glTF file, this extension is defined on the texture object, so it seems logical that we define this cgltf extension data on the cgltf_texture object. This PR adds a new flag, has_basisu and a new cgltf_image property, basisu_image to cgltf_texture. This solution allows loaders that do not support KTX2 and basisu textures to continue loading any fallback texture that may be defined on the model.

I considered making a small change, where we can #define SUPPORT_BASISU, remove this new cgltf_texture::basisu_image, and instead just load the basisu image directly into cgltf_texture::image. Open to suggestions here, but both seem functionally equivalent.

If you'd like to play with this extension, here are some helpful resources to get started:

• Instructions for converting existing glTF model textures to KTX2+basisu can be found in the artist guide: https://github.com/KhronosGroup/3D-Formats-Guidelines/blob/main/KTXArtistGuide.md
• A developers guide for KTX2 and basisu can be found here: https://github.com/KhronosGroup/3D-Formats-Guidelines/blob/main/KTXDeveloperGuide.md
• To load basisu textures into your engine, you'll only need the basisu_transcoder.cpp from Binomial. The transcoder also defines a helpful and compact ktx2 loader. See How to configure and use the transcoder for tips to get started.

[emackey]

For those interested, here's the press release where Khronos announces KTX2 and the KHR_texture_basisu extension:

https://www.khronos.org/news/press/khronos-ktx-2-0-textures-enable-compact-visually-rich-gltf-3d-assets

and some 3rd party analysis:

https://gfxspeak.com/2021/04/26/khronos-compresses-everyone/

[abwood]

After hooking up KHR_texture_basisu to cgltf_write, I see now that we do in fact need to retain both cgltf_texture::image and cgltf_texture::basisu_image. This allows models to "round trip" through cgltf parsing and cgltf writing without losing any possible fallback image that may also be defined on the texture object. So I think the implementation that I have here is preferred.

This is ready for review.

[jkuhlmann]

Looks good to me! Thanks!