Add physics materials and filtering similar to KHR/MSFT physics

[aaronfranke]

Preview: https://github.com/aaronfranke/gltf-extensions/tree/msft-style-mat-filter/extensions/2.0/OMI_physics_body

These changes add physics materials and filtering very similar to Eoin's Microsoft/KHR physics repo here: https://github.com/eoineoineoin/glTF_Physics

I did not include any example files for these. However, this is not so important because the goal here is alignment with the other spec. Also, these are not easy to implement in Godot Engine, since it uses per-body filtering instead of per-shape (which is worse btw), and its physics materials work differently (worse), so it's difficult to support these features there. For both it can still be done, but not so cleanly, and I haven't had time yet to do it.

As part of alignment, this PR also adds a new "gravityFactor" property to motion. This was discussed as desired and added to MSFT physics a long time ago, but I guess we missed that before now.

I also did some minor formatting changes, such as changing * unordered lists to - to match Khronos style, and reordering properties to match the contents of Eoin's repo.

[eoineoineoin]

Aaron brought my attention to this from a PR in KHR_physics_rigid_bodies and I'd like to drop in a comment to say I'm a little disappointed to see this.

While it's great that this specification is converging on KHR_physics_rigid_bodies, this repo now contains large chunks which have been copied verbatim from KHR_physics_rigid_bodies.

I think having two identical-but-different specifications results in unnecessary user confusion, fragmentation, and interoperability problems, which ultimately hurts users and the glTF ecosystem. I'd ask you to please reconsider where energy is best expended.

[antpb]

Hey @eoineoineoin ! I just want to be clear that our efforts here are not in an attempt to be a KHR spec or conflict with one, we are experimenting within the OMI vendor extension and aligning on the needs we have in our implementations. While, it is nice whenever an extension we rally behind works for wider groups and can be ratified at the KHR level, it is not our focus. I don't think its fair to ask that we reconsider working on this. We work within the OMI space to move fast and learn from implementations of our specs.