Best practices for extensions and fallbacks

Variations of this have come up in recent conversations for texture transforms and Draco extensions:

From `EXT_texture_transform` —

> **Implementation Note**: For maximum compatibility, it is recommended that exporters generate UV coordinate sets both with and without transforms applied, use the post-transform set in the texture `texCoord` field, then the pre-transform set with this extension. This way, if the extension is not supported by the consuming engine, the model still renders correctly. Including both will increase the size of the model, so if including the fallback UV set is too burdensome, either add this extension to `extensionsRequired` or use the same texCoord value in both places.

From `KHR_draco_mesh_compression` —

> To prevent transmission of redundant data, exporters should generally write compressed Draco data into a separate buffer from the uncompressed fallback, and shared data into a third buffer. Loaders may then optimize to request only the necessary buffers.

***

While I think it's worthwhile that we're taking pains to ensure assets _can_ include fallback behavior for unsupported extensions, I am skeptical that tooling will actually do these things. For example, writing three buffers for Draco is contrary to our advice in [Best practices for .gltf / .glb ](https://github.com/KhronosGroup/glTF/issues/1117), and assumes engines that support no extensions will still be clever enough to avoid loading extra buffers.

And as a developer using exporters to create experiences (where my assets are not re-distributed) I would certainly want my tooling to provide out-outs on these duplicate textures, UVs, and buffers. I'm not sure what an exporter should do by default, but I would lean toward saying duplication is to be avoided by default, and to provide e.g. **Runtime** or **Compatibility** presets.

To complement our advice on fallbacks, perhaps we should also provide best practices on use of glTF extensions. A first pass at such language:

> Certain glTF assets are reproducible within the core glTF specification, but for whatever reason (often performance) include or require extensions. Such extensions include:
>
> * KHR_draco_mesh_compression
> * KHR_materials_unlit
> * EXT_texture_transform
>
> In these cases, we consider it **best practice** for asset distributors[1] to provide _as few required extensions as possible_. Where implementing fallbacks may be impractical (e.g. compression) distributors should prefer to remove these extensions — decompressing data or baking texture transforms to UVs — rather than providing assets with such extensions required. End-users may re-apply optimizations as needed, via the glTF tooling ecosystem[2].
>
> Where reasonable fallback behaviors are possible (e.g. `KHR_materials_unlit`), distributors are
> encouraged to use their best judgment on what to provide.

[1] By "asset distributor" I mean tools like Sketchfab, Google Poly, Microsoft Remix3D, and any others that are agnostic to any particular engine. The Unity Asset Store could be an exception, as it services exactly one engine.
[2] Having the ability to both add and remove extensions via glTF-Toolkit might increase the odds of this actually happening.

Start by reviewing the fallback guidance quoted from EXT_texture_transform and KHR_draco_mesh_compression, then compare it with the Best practices for .gltf / .glb discussion in issue 1117. Done means reaching agreement on extension and fallback recommendations and documenting the resulting guidance, including any glTF-Toolkit implications.

Written by the indexing model from the issue text.