Define behavior for non-invertible/representible XRRigidTransforms

[alcooper91]

It is possible for an XRRigidTransform to be generated with a translation that cannot be represented in its matrix attribute, since XRRigidTransform's position/orientation take DOMPointInits (typically doubles), and the matrix representation is a Float32Array (essentially floats).

For example:

(new XRRigidTransform({x: 1e50})).matrix
Float32Array(16) [1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, Infinity, 0, 0, 1]

It is also possible to store values that are large enough that typical inverse algorithms on the matrix fail to invert them (though these numbers end up being represented as Infinity in the .matrix value anyways). Even attempting to do the inverse with the decomposed position/orientation, could result in numbers that could overflow.

For Example, if 1e50 were instead ~DBL_MAX, the below would cause an overflow, even with most internal representations:

a=new XRRigidTransform({y: 1e50, z: 1e50}, {x: 0.3826834, w: 0.9238795})

a.inverse.position
DOMPointReadOnly {x: -0, y: -1.4142135623730944e+50, z: -4.938409389042487e+42, w: 1}

Examples taken from discussions with @klausw who can correct me if I've misrepresented any of these. This arose because of investigations due to a Chrome bug: https://crbug.com/1258611

cc @toji

[klausw]

Alex's second example is a transform where the exact result of the inverse has components that are too big to fit in a 64-bit double.

Specifically, the {x: 0.3826834, w: 0.9238795} quaternion is a 45-degree rotation around the X axis, and its translation has equal Y and Z values. Inverting that requires negating the translation and then applying the inverse rotation to the translation vector. The rotation matrix has sin(45 degrees) and cos(45 degrees) elements, so the new Y value is -(0.707*Y + 0.707*Z), a value with magnitude sqrt(2) times the old y/z values. If the old Y/Z values are near the DBL_MAX limit, the correct new value's magnitude is greater than DBL_MAX and can't be represented as a finite 64-bit double value, no matter how the internal values get calculated.

Depending on the implementation, there may also be cases involving position attributes near DBL_MAX where internal calculations of the inverse may overflow even in cases where the final result could be correctly represented as a finite double value. This may be fixable in individual implementations, but still leaves the issue of non-representable inverses as in the previous example.