OMI_physics_body: Rename rigid to dynamic, remove character/vehicle

[aaronfranke]

The term "rigid" can be a point of contention, since it can have 2 different meanings depending on the context. The suggestion is to rename this to "dynamic" to avoid the problem, such that OMI physics no longer contains "rigid". Instead, we will refer to these "dynamic" bodies as "bodies simulated with rigid body dynamics".

This PR also removes the character/vehicle types. Initially I was in favor of having these because I believe that specifying the correct "type" of body is critically important. However, this has been contentious. After thinking about it more, I have realized there is a way we can have our cake and eat it too: Have the importer work with different possibilities in the enum than what's possible in the file. This means we don't need to have a "vehicle" type in OMI_physics_body.

• For example, a vehicle extension may want to override the body type to "vehicle" so Godot generates a VehicleBody3D node. So we can have a GLTF file with { "type": "dynamic" }, then the Godot importer imports a GLTFPhysicsBody data structure and maps "dynamic" to "rigid" as the default type of dynamic body. This would generate a Godot RigidBody3D by default, but another extension can modify the GLTFPhysicsBody data structure in-between the data reading and node generation steps, setting the type to "vehicle", so that Godot will generate a vehicle even though the GLTF file had the type set to "dynamic".

  • This means that the GLTF file would have an enum of ["static", "kinematic", "dynamic", "trigger"] and the Godot importer would instead work with an enum of ["static", "kinematic", "character", "rigid", "vehicle", "trigger"], which works fine as long as the Godot importer maps the types when reading the data.

  • This does depend on the importer having data reading and object generation split into 2 different parts, and allowing the importer's extension code to affect other extension data, which I don't know for sure is the case in all importers, but I think this would be a reasonable expectation to have (and it's also only needed in engines with singular object types and a dedicated vehicle type, Unity importers need not be concerned with this detail).

These changes bring OMI_physics_body closer to MSFT physics.

[lyuma]

Discussed in the meeting. We all agreed that this change makes sense. The cases of "character" and "vehicle" can be resolved by building extra extensions. Engine implementers (such as Godot) can use vendor extensions in the short term.