This fixes a compile warning on GCC 13.3.0 where it warns about the
use of Variant within this class with no key function. Since the class
was almost a CRTP base class, make it a real one.
IntegerOrCalculated and NumberOrCalculated's T types don't have a
to_string() method because they're i64 and double respectively, so use
String::number() for them instead.
Also rearrange this method to avoid checking the variant's contents
multiple times.
To be properly compatible with calc(), the resolved() methods all need:
- A length resolution context
- To return an Optional, as the calculation might not be resolvable
A bonus of this is that we can get rid of the overloads of `resolved()`
as they now all behave the same way.
A downside is a scattering of `value_or()` wherever these are used. It
might be the case that all unresolvable calculations have been rejected
before this point, but I'm not confident, and so I'll leave it like
this for now.
This reverts commit 76daba3069.
We're going to need separate types for the JS-exposed style values, so
it doesn't make sense for us to match their names with our internal
types.
The length resolution context might be needed even when resolving an
integer value, since it might contain a sign() function with length
values inside. This fixes a WPT subtest.
