Test models for 2.0.x specification clarifications

There are a few issues in the specification repository that point out corner cases and ambiguities, and that are supposed to be resolved with an upcoming 2.0.x release of the specification. The following are a few test models that are supposed to serve as test cases here.

---

### About [Clarify restrictions for nodes with a defined matrix](https://github.com/KhronosGroup/glTF/issues/2547):

This revolves around animations that affect morph targets, and which restrictions these animations should or should not imply. For details, refer to the issue. The following is a test asset that was already posted [in an issue comment](https://github.com/KhronosGroup/glTF/issues/2547#issuecomment-3706347277). It is the `SimpleMorph` asset, containing a simple morphed and animated mesh primitive, but modified so that the mesh is attached to a node that contains a `matrix`:

[SimpleMorphWithMatrix.gltf.txt](https://github.com/user-attachments/files/28193925/SimpleMorphWithMatrix.gltf.txt)

This works in three.js and Babylon.js.
Additional test cases are TBD.

---

### About [Clarify mixing morphed and non-morphed primitives](https://github.com/KhronosGroup/glTF/issues/2154):

The following is essentially also the `SimpleMorph`, but with _two_ mesh primitives, once without the morph targets, and once with the morph targets:

[PartiallyMorphedPrimitives.gltf.txt](https://github.com/user-attachments/files/28193991/PartiallyMorphedPrimitives.gltf.txt)

This seems to work in three.js and Babylon.js. (The validator reports an error, but that is tracked independently).

Aside: There seems to be a strange flicker in Babylon.js, where the primitive goes into its unmorphed state for 1 frame, but that also appears in the `SimpleMorph`, and is therefore probably unrelated:

---

### About [TRS decomposition with negative scale makes camera matrix non-unique](https://github.com/KhronosGroup/glTF/issues/2468):

This is the most tricky one. The behavior for cameras when non-uniform, negative, or zero scales are involved is not entirely clear. And there are many _possible_ configurations that may have to be tested. I tried to cover some of them in the following asset:

[CameraTransformsTest.gltf.txt](https://github.com/user-attachments/files/28194120/CameraTransformsTest.gltf.txt)

The asset contains a unit cube and a camera pointing at that cube. The node that the camera is attached to is:

- node0: Move camera to view the cube
- node1: Animated scale (details below)
- node2: Rotation about 45 degrees around the z-axis
- camera

The `scale` property of `node1` is animated. Each animation starts at (1,1,1), goes to the 'special value', remains there for 1 second, and goes back to (1,1,1).

- `Constant`: The default animation that is played by most viewers, without a 'special value' (i.e. a constant (1,1,1) scale)
- `WithZero`: The 'special value' is (0,0,0)
- `WithNegative`: The 'special value' is (-1,-1,-1)
- `NonUniform`: The 'special value' is (1,2,1)
- `NonUniformNegative`: The 'special value' is (1,-2,1)

Both three.js and Babylon.js don't "properly" display all of them. For example, both viewers don't animate the one that goes to (0,0,0) - the cube simply disappears for a moment. The `NonUniform` one seems to work, with the caveat that the viewers differ in their treatment of the camera on a _much_ lower level: three.js takes the aspect ratio from the _window_, whereas Babylon.js uses the aspect ratio from the _camera_. (Related to https://github.com/KhronosGroup/glTF/issues/2217 and already mentioned in https://github.com/KhronosGroup/glTF/issues/1822 ). The `NonUniformNegative` looks pretty fancy in both of them. Looks like some relativistic effect of crossing the event horizon of a black hole or something. But in any case, the "right" behavior still has to be defined here.

Start by reviewing the linked specification issues 2547, 2154, and 2468, then inspect SimpleMorphWithMatrix.gltf.txt, PartiallyMorphedPrimitives.gltf.txt, and CameraTransformsTest.gltf.txt. Compare the assets in three.js and Babylon.js; done requires agreed expected behavior and complete test coverage for the 2.0.x clarifications, which the issue does not yet define.

Written by the indexing model from the issue text.