Bug 1849630 [wpt PR 41567] - Refactor how wpt handles fuzzy color matching, a=testonly

Bug 1849630 [wpt PR 41567] - Refactor how wpt handles fuzzy color matching, a=testonly

Automatic update from web-platform-tests
Refactor how wpt handles fuzzy color matching

Both computed and valid color tests previous looked for exact matching
of strings. This became untenable with color-mix and relative color
syntax because of potential float rounding errors. e.g.:

color-mix(in lch, color(srgb 1 0 0) 100%, black)
Will simply return red in the lch color space.
chromium: lch(54.29     106.854   40.856)
firefox:  lch(54.2905   106.846   40.855)
safari:   lch(54.288002 106.83335 40.852623)

These numbers are all obviously extremely similar. If we want more
alignment on how floats are serialized, it should be tested elsewhere.

This CL adds a custom comparsionFunction to css valid and computed
tests. For colors this test will strip out numbers and compare them
with an epislon, then compare other parts of the string directly to
validate formatting and color space. The algorithm itself is moved
from computed-testcommon.js

Bug: 1474922
Change-Id: I30f9271db6aac0392848ae09e0defd48f5aa2dcc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4799569
Commit-Queue: Aaron Krajeski <aaronhk@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1188331}

--

wpt-commits: 34fa76976c8bce2eaa2e3cb97c88b2358ffd71ae
wpt-pr: 41567