Re-using materials on meshes with different attributes

Related to
- https://github.com/KhronosGroup/glTF/issues/1023

glTF is used more and more for interchange usecases. Even if glTF may not have been designed with that in mind, it is what it is.
Some of the spec make that hard, for example the requirement that all accessed attributes MUST exist on a primitive, or else the file is valid.
As an example, reusing a material that puts a texture in UV1 on a mesh that only has UV0 results in an invalid file. To make the file valid, the material must be duplicated, which increases the amount of data transmitted and reduces the usefulness for interchange. If the material is animated (e.g. with KHR_animation_pointer) then there is even more data to be duplicated to make sure the resulting file is still "validator valid".

Applications treat that differently right now. Because reusing materials in this fashion is very common, and nobody likes to suddenly have two materials instead of one to author, many applications seem to have opted for making it work nonetheless.

The attached file ✅ works / ❌ fails in
✅ Babylon
✅ Gestaltor
✅ Unity
✅ Unreal
✅ Khronos Sample Viewer
❌ three.js/model-viewer
❌ glTF Validator

UV missing in one object
[UVMismatch_UV1.glb.zip](https://github.com/KhronosGroup/glTF/files/13921185/UVMismatch_UV1.glb.zip)

UV missing in all objects
[UVMismatch_UV2.glb.zip](https://github.com/KhronosGroup/glTF/files/13921154/UVMismatch_UV2.glb.zip)

Personally I think it would be better if this was allowed, and there were clear rules what happens when accessing attributes that don't exist.
Behaviours found in the wild:
- last valid attribute of that sort is used (e.g. when UV0 and UV1 are defined and UV2 is accessed, UV1 is used) (Unity does that)
- placeholder attribute is filled with zeros (Gestaltor/Khronos Sample Viewer/Babylon do that)
- entire scene stops rendering (three.js)

Start with related issue #1023 and inspect UVMismatch_UV1.glb.zip and UVMismatch_UV2.glb.zip. Compare the listed application and glTF Validator behaviors, then define the spec change and explicit missing-attribute rules needed for the issue to be resolved.

Written by the indexing model from the issue text.