Bug 1626471 [wpt PR 22585] - geometry: Propagate NaN in min/max operations, a=testonly

Bug 1626471 [wpt PR 22585] - geometry: Propagate NaN in min/max operations, a=testonly

Automatic update from web-platform-tests
geometry: Propagate NaN in min/max operations (#22585)

Currently in some geometry classes we are using std::min() and
std::max() over numbers specified in IDL as "unrestricted double",
meaning they could take the special value NaN. These STL helpers
internally use the < operator, as in

    std::min(a, b) = a < b ? a : b.

However, the IEEE 794 < operator always returns false when _either_
operand is NaN, so the result of min(0, NaN) and min(NaN, 0) could,
confusingly, be different.

This is difference is in fact visible through JavaScript. For instance,

    new DOMQuad({ x: NaN }, { x: 0 }, { x: 0 }, { x: 0 }).getBounds().x

gives NaN, but

    new DOMQuad({ x: 0 }, { x: 0 }, { x: 0 }, { x: NaN }).getBounds().x

gives 0.

A similar problem is present for DOMRect/DOMRectReadOnly as well.

This CL implements [1], which is to adopt semantics similar to
JavaScript's Math.min() and Math.max(), which propagates NaN from either
operand. This also aligns our behavior with WebKit.

[1]: https://github.com/w3c/fxtf-drafts/pull/395

Fixed: 1066499
Change-Id: Id9a4282fa00dafcfe9c5616643efbe2eaace411e
--

wpt-commits: 452d7c5e1a0b683ccfbfaf6fcac833b3e96bb32e
wpt-pr: 22585