gltfpack: glTF 2.1 support

[zeux]

Khronos Group is working on glTF 2.1 specification: KhronosGroup/glTF#2585; I am not sure if gltfpack will support it in full or just partially, but I'll create a tracking issue that notes potential changes we'd need to make and the complexity based on initial review.

Note: it's too early to actually work on supporting these features; that would need an actual spec. Also all of these would need support in https://github.com/jkuhlmann/cgltf before being added to gltfpack.

Complex Scenes:

• External Assets - probably pretty involved
• Bounding Volume Hierarchy - fairly straightforward after cgltf support
• Shapes - fairly straightforward after cgltf support
• Packaging External Assets - similar to "external assets"
• Unified File References - might be as simple as preserving these, not sure
• Multiple Scene Deprecation - can be implemented as a gltfpack warning; we already have some limitations wrt multiple scenes around instancing anyway.

Promoted Extension Functionality:

• EXT_texture_webp - already supported as an extension, might need minor tweaks for promotion
• KHR_materials_emissive_strength - already supported as an extension, might need minor tweaks for promotion
• KHR_mesh_quantization - already supported as an extension, might need minor tweaks for promotion?
• KHR_node_visibility - very straightforward once cgltf support is there

Quality of Life:

• Thumbnails - very straightforward with cgltf support (just preservation of existing thumbnail)
• 64-Bit Binary File Format - should be fairly straightforward with cgltf support
• Non-Sequential Attributes - already supported by gltfpack I believe
• Accessor Component Type Definitions - very straightforward with cgltf support
• Unique IDs - should be fairly straightforward with cgltf support (similar to extras, we could also expose a variant of -kn that is keyed on unique id and not name)

[zeux]

I think the general notion in everything above is additions/tweaks within a single file look quite benign; the most involved one is probably "bounding volumes/shapes", not because it's difficult but just because it's a new set of node-attached objects we'd need to preserve. But this is quite similar to e.g. lights in structure and just requires cgltf/JSON plumbing.

Multi-file (external assets, packaging external assets, unified file references) might be harder depending on what we need to do here. But maybe we can treat this as a separate layer on top of the existing structure - as long as the references can't point to the current file (which seems disallowed), and can't rely on implicit structure like object ids that gltfpack doesn't preserve, it should be okay.

We would still limit gltfpack to a single file only. Any dependent files can be processed separately and externally. A separate flow would need to be established for assets with sharing (e.g. texture compression), but that seems orthogonal to glTF 2.1 per se.