Use glam for computing gLTF node transform

[richardhozak]

Objective

gltf-rs does its own computations when accessing transform.matrix() which does not use glam types, rendering #11238 useless if people were to load gltf models and expecting the results to be deterministic across platforms.

Solution

Move the computation to bevy side which uses glam types, it was already used in one place, so I created one common function to handle the two cases.

The added benefit this has, is that some gltf files can have translation, rotation and scale directly instead of matrix which skips the transform computation completely, win-win.

[richardhozak]

@Jondolf this might be of interest to you, since you've authored #11238

[richardhozak]

I've addressed the comment on node_transform functions.

Also to share a little success story I've had with this:

Previously my game used bevy_obj to load levels and generate colliders from the mesh it loaded, as obj is simple format, it only has mesh information without any transforms, this worked perfectly when loaded into physics system.

Now, I've wanted to transition to gltf to add more features to the level, to use it as a scene format, I've had so many attempts at this which all failed, as the physics engine handled generating colliders just from meshes, now I realized I need to add all the transforms so the colliders can be properly sized and positioned. When implemented, I was overjoyed but all hope was lost when I found the physics simulation is no longer deterministic.

I've made this PR yesterday as a shot in the dark, hoping it would fix the determinism, but had not verified it. Today, I've included this change in my code and am happy to say that the determinism works again!