Allow double precision transformations

[ShaddyDC]

Hi, it's me again, trying to deal with unreasonably large numbers.

We are using glTF for objects that may be at very large coordinates. It is important that these coordinates remain fixed to be able to fit into existing workflows with other file formats that are already used that way.
To deal with precision issues, we center the objects around their origin and then use transformations to move them into their final positions.
Unfortunately, that doesn't work reliably when our transformations are limited to f32.
Another, potentially better-worded use case is here, with a focus on tiles in a geospatial coordinate system.

Afaict, the specification doesn't say anything about a numeric size limit for matrix components, and since it's saved as json, they should be able to be arbitrarily large.
Naturally, actually supporting arbitrarily large numbers is unreasonable, but I feel like f64 is useful commonly enough to be worth it.

[scottmcnab]

I'd like to upvote this also, specifically for the use-case of accurately handling ECEF models for 3D Tiles.

While centering the meshes around the origin is usually sufficient numeric precision for the model itself, the final Node transform to ECEF coordinates has insufficient precision due to the Node matrix / translation fields using f32 representation. Upgrading these field storage types to f64 should help resolve this.