perf(core): overhaul css matching, cascade, and application - #11361

Skipping unchanged values (96bea36) is unsound when a property that
stopped matching overlaps one that is being skipped. A shorthand and its
longhands write the same style properties, so unsetting `margin-top`
clears what `margin` had set - and `margin`, being unchanged, was no
longer re-applied afterwards.

    label { margin: 4; }
    label:highlighted { margin-top: 8; }

left `marginTop` at 0 instead of 4 once the pseudo class went away.

Shorthand css names are now registered, and the diff falls back to
applying every matched value whenever something was removed and either
side of the removal is a shorthand. Removals of properties that cannot
overlap - the common case - still take the fast path.

`ShorthandProperty.register` defined the expanding setter on
`cls.prototype.PropertyBag` - the bag's constructor rather than its
prototype - so bag instances never got it and shorthands reached the
apply step unexpanded. Bag keys keep the position of their first
declaration, so an early `margin` was written after longhands that
should have lost to it:

    label { margin: 1; }
    .a    { margin-top: 8; }
    #x    { margin: 4; }

left `marginTop` at 8 rather than 4, ignoring the most specific rule.

The cascade is defined on longhands - a shorthand declaration is
equivalent to declaring each of its longhands in its place - so the
expansion belongs in the parser, next to the other per-declaration work.
`fromAstNode` now expands there. Source order stays meaningful, the
converter runs once per declaration instead of once per view per update,
and the resulting values are shared, so the unchanged-value diff still
compares by identity.

Shorthands whose value is a `var()` or `calc()` expression are left
alone: they can only be resolved per view, and converting them early
throws on the unevaluated text. They keep the existing evaluate-then-
apply path, and are now the only case the shorthand overlap guard has to
cover.

The dead `propertyBagDescriptor` goes with it.

Measured against upstream with the added benchmark (median, best of
three, each run in its own process):

                                              JIT
  re-apply 200 views, nothing changed        2.70x
  add 30 stylesheets + restyle 200 views     1.79x
  toggle a pseudo class on 200 views         1.66x
  style 400 views (angular attribute css)    1.25x
  load 30 components                         1.20x
  style 400 views (plain css)                1.01x
  build a style scope                        0.92x

Re-apply drops from 4.13x and the toggle rises from 1.14x: expanding
turns two shorthand declarations into eight longhands, so there is more
to diff per view, but a removal no longer forces everything to be
written again.

…e scope

Every `StyleScope` built its own `StyleSheetSelectorScope` over the whole
merged rule list, so a version bump re-sorted every application rule into
fresh lookup maps for every scope in the app. Angular registers one
stylesheet per component the first time it is used, which made a
navigation cost O(components x all rules x scopes). It also meant several
scopes wrote `pos` onto the same shared `RuleSet` selectors, and whichever
built last won.

Browsers do not keep one merged index either: in Blink each `TreeScope`
has a `ScopedStyleResolver` holding that scope's rules partitioned into
`RuleSet`s, and `ElementRuleCollector` walks several of them and merges
the hits. So the application rules are now indexed once, globally, and a
`StyleScope` only indexes its own stylesheets. `matchSelectors` gathers
candidates from both into one array and resolves them together.

Ordering follows the cascade rather than a single running counter: a
specificity tie breaks on source order, and source order across
stylesheets is (stylesheet, position within it). Selectors carry the tier
they were indexed in and sort by `(specificity, tier, pos)`, so positions
only have to be comparable within a tier - which is what makes the shared
index possible.

Two details worth knowing:

- Rules registered on behalf of a particular stylesheet (`scopedTag`) stay
  in the shared index and are filtered at match time for scopes that never
  loaded that stylesheet. The filter is skipped entirely - the common case
  - when no such rules exist.
- The application rules are only ever appended to outside of a livesync or
  a `removeTaggedAdditionalCSS`, so those two bump a reset counter and
  everything else appends to the existing index instead of rebuilding it.

  add 30 stylesheets + restyle 200 views     1.78x
  load 30 components                         1.34x   (was 1.20x)
  toggle a pseudo class on 200 views         1.65x
  style 400 views (angular attribute css)    1.31x
  re-apply 200 views, nothing changed        2.45x

…atch

`CssState.onChange` unsubscribed from every dynamic dependency, re-matched,
then subscribed to whatever came back - unconditionally. A re-match usually
lands on the same dependencies, so that removed and re-added the identical
listeners, and toggled the widget-level pseudo class handlers off and back
on for nothing.

Matching does not read the subscriptions, so the match now runs first and
its change map is compared against the one already applied. Only a real
difference touches the listeners. Both empty maps compare equal even though
they are distinct objects.

Toggling a class on 200 loaded views: 27.2ms -> 23.5ms on its own, and
46.6ms -> 22.1ms against upstream with the rest of the branch. A benchmark
scenario for that path came with it - the existing ones drove
`updateDynamicState` directly and never went through `onChange`.

Shorthands are expanded while parsing, but one holding a `var()` cannot
be: a single `var()` may substitute the value of several longhands at
once, so there is no way to tell what belongs where until substitution
has happened. Those declarations stayed keyed by the shorthand, which
left the one case where two entries in a view's property bag write the
same style property - and so the one case where unsetting a property
that stopped matching could clear a value being skipped as unchanged.
That is what the shorthand overlap guard was covering.

CSS answers this with pending-substitution values: the longhands are
filled with a placeholder, cascaded like any other value, and the
shorthand is parsed at computed-value time once the substitution is
done. Doing the same here means a declaration is only ever keyed by a
longhand, whatever its value looks like.

So `fromAstNode` now emits one placeholder per longhand, discovering the
longhand names by asking the shorthand's converter for an unset value -
deferred to first use, because the longhand properties a converter closes
over are not initialized yet while the shorthand is being registered.
`setPropertyValues` resolves each placeholder once per view no matter how
many longhands point at it, after the css variables are up to date, and
diffs the resolved values so an unchanged shorthand is still skipped.
Inline styles resolve them the same way.

With that the overlap is structurally impossible, so the guard and
`isCssShorthandProperty` are gone: a removal no longer forces every
matched value to be written again.

  re-apply 200 views, nothing changed        2.90x   (was 2.54x)
  add 30 stylesheets + restyle 200 views     1.84x   (was 1.62x)
  toggle a class on 200 loaded views         2.12x
  toggle a pseudo class on 200 views         1.76x

Ref: https://drafts.csswg.org/css-variables/#variables-in-shorthands