[css-color] `epsilon` in `fuzzy_test_computed_color` obscures too many implementation issues.

[romainmenke]

For example:

color(from color(srgb 0.25 0.5 0.75) prophoto-rgb r g b)

Computed values:

chrome:  color(prophoto-rgb 0.37494  0.416475 0.663752)
safari:  color(prophoto-rgb 0.374929 0.416494 0.663803)
firefox: color(prophoto-rgb 0.374928 0.416497 0.663803)

All values are different while all browsers also pass this test:

fuzzy_test_computed_color(`color(from color(srgb 0.25 0.5 0.75) prophoto-rgb r g b)`, `color(prophoto-rgb 0.374928 0.416497 0.663803)`, 0.001);

The value produced by colorjs is:

color(prophoto-rgb 0.3749291293 0.416494473 0.6638026693)

Assuming that colorjs is up to date with all spec edits it seems that only Safari is correct and the Firefox, Chrome and the expected outcome are incorrect.

But none of this is surfaced because the precision is reduced so much by the epsilon argument.

---

Would it make sense to instead have a dynamic comparison?
We could determine the precision of the computed value and match that in the expected value.

This would still allow implementations to pick the precision when serializing (as this is unspecified in https://drafts.csswg.org/css-color-4/#serializing-color-values).
But then tests would check that whatever is serialized is actually fully correct.

[romainmenke]

@svgeesus @weinig thoughts?