The specification uses the term "tokens" to refer to a sequence
of V8CSSUnparsedSegment objects, and CSSUnparsedValue has adopted
this terminology. While it is usually a good idea for Blink
to mirror the language used in specifications, "tokens" is very
confusing here, since it always means CSSParserTokens in every other
place in the style code.

Bug: 487117772
Change-Id: I2dc132c4e618e398e1f8bdabc03a8d2ab6c118e7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7606599
Commit-Queue: Anders Hartvoll Ruud andruud@chromium.org
Reviewed-by: Steinar H Gunderson sesse@chromium.org
Cr-Commit-Position: refs/heads/main@{#1590040}

CSSUnparsedValue exposes a special stringification function
ToUnparsedString() in addition to the regular toString().
The documentation says it returns "tokens without substituting
variables", but it's not clear what this means; we don't substitute
any variables in CSSStyleValue::toString() either.

This CL makes ToUnparsedString() private (and renames it).
Clients needing to serialize a CSSUnparsedValue can do so via
the normal toString() function. (If ToUnparsedString() existed
for performance reasons, that should have been documented.)

Also, the /**/-"fixup" pass over the value has been folded into
ToStringInternal(). This is to make it easy to find the canonical string
representation of this value within CSSUnparsedValue (without going
through a CSSValue).

The main point of this CL is to prepare for validating
the "argument grammar" of the value during the StyleValue-to-CSSValue
conversion in StylePropertyMap (which requires item (2) above).

We now jump through additional hoops to ultimately get a string
from the outside of CSSUnparsedValue, but there should otherwise
be no behavior change.

Bug: 484751092
Change-Id: I5db45ad85f780c67a2ea3ba8482c390ebab10068
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7600415
Commit-Queue: Anders Hartvoll Ruud andruud@chromium.org
Reviewed-by: Steinar H Gunderson sesse@chromium.org
Cr-Commit-Position: refs/heads/main@{#1590041}

CSS Typed OM has a concept of a value "matching a grammar" (or not)
upon assignment to a property [1]. For CSSUnparsedValues, we currently
don't perform any significant validation, and as a consequence
we allow "invalid" CSSUnparsedDeclarationValues to be created
(causing DCHECKs later in the pipeline).

This CL makes sure values can be parsed using CSSVariableParser::
ConsumeUnparsedDeclaration before assignment.

We're still not handling the value in the context of the destination
property, which we probably should. This is also a problem with
current state of things, however, so for now the goal is primarily
to avoid the DCHECKs in Issue 484751092.

Finally, I opened an issue against the specification [2], which
currently doesn't define any of this.

[1] https://drafts.css-houdini.org/css-typed-om-1/#create-an-internal-representation
[2] w3c/csswg-drafts#13547

Fixed: 484751092
Change-Id: Id7f888a6df8c02ade24910900f5d01909cb2dfad
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7595347
Reviewed-by: Steinar H Gunderson sesse@chromium.org
Commit-Queue: Anders Hartvoll Ruud andruud@chromium.org
Cr-Commit-Position: refs/heads/main@{#1590110}