Rigid Body Physics layout proposal

Currently, I am trying to implement my own glTF loader, and the first thing I've realize is that, as of today, things are already very complicated, specially when dealing with extensions.

I was thinking about the issue of supporting rigid body physics #1135 , and I've got a severe case of cold sweat just thinking about how much complicated the schema would become, I really don't like that prospect.

Thinking about potential solution, I've came with this idea: Instead of integrating rigid body content within the gltf schema, what about creating a completely new schema for physics? ... maybe _plTF_ ?

So, in essence, the current glTF schema and files would remain as they are, and a new, independent plTF schema would be used to process plTF files, a model with rigid body physics would look like this:

```
bigcat.gltf
bigcat.pltf
bigcat.bin
bigcat.texture0.png
```

This has a number of advantages:

- It keeps visual and logical domains separated from each other (MVC pattern?)
- plTF schema can begin being designed right now, because it would not affect glTF roadmap, no need to bump up glTF version.
- Existing tooling and solutions for glTF don't need to be updated, they will simply ignore the plTF file.
- If well designed, glTF and plTF schemas can grow features and extensions independently one from the other.
- glTF and plTF could be cross compatible between versions, for example: glTF ver 2.0 to 2.5 could be cross compatible with plTF 1.0 to 1.7.
- If desired, graphics and physics toolings can be developed indenpendently, reducing development time; specially, graphics tooling will be developed by graphics engines specialists, and physics tooling, by physics engines specialists.
- Support for pure offline/server physics simulation; in this case, if plTF is designed so it contains everything it needs, it could be used ignoring the glTF file, which would be considered the "visual representation of the rigid body", this could be very convenient for multiplayer games where the server runs the physics without any graphics head.

Hurdles:

- GLB files would need to handle the pltf files as a new chunk.
- If pltf somehow needs access to binary data, it can do so in the same way as gltf.
- The small breaking change is that both gltf and pltf files need to reference each other, in fact, I would allow this cross referencing to let me load the pltf first, and from there, find the gltf file, or the other way around. both gltf and pltf would be considered first class citizens, not one superseded to the other.
- glTF and plTF files will probably need some sort of cross-binding for the sake of matching their visual and physical representations. This could be done by extensions, or by adding an optional gltfId PhysicalNode to the Node object schema.

Finally: by no means I am an expert in rigid body simulation, I'm mostly on the graphics side; precisely because I'm biased towards graphics, I don't want to deal with physics stuff within the glTF schema. I'm sure rigid body experts will think the same way around, and will love to have their own, clean schema.

Start by reading issue #1135 and the proposal's discussion of glTF, plTF, and GLB chunks. Review the stated requirements for cross-referencing, binary data access, and visual/physical node binding. Done would require a project decision on whether to pursue a separate physics schema and a defined design scope.

Written by the indexing model from the issue text.