Call DisplayList builder methods directly from dart canvas

[flar]

This is a resubmit of #29470 with fixes for the golden image failures down the line. This is a WIP until I can confirm that it fixes the failures in the downstream tests.

The following description is copied from the original PR:

Fixes flutter/flutter#93415

This is a big step along the way towards eventually deleting the SkPicture code and should provide a tiny performance boost for DL because it bypasses the current roundabout way of filling the DL records.

Current mechanism: flutter::Canvas => SkCanvas calls => SkDL adapter => DLBuilder => DL
After this patch: flutter::Canvas => DLBuilder calls => DL

There is a lot of reworking of some of the DL code which is mostly logistical. We used to have 2 or so different ways of describing what attributes and properties each rendering op used or exhibited. Because this PR was going to add yet another mechanism that needed to know mostly the same information, I took the opportunity to consolidate all of our various Ops-flags mechanisms into a common "DisplayListAttributeFlags" class. Now 4 different mechanisms use this data:

• Bounds calculator to determine which attributes contribute to the bounds of an Op
• Canvas Adapter to determine which attributes to sync from an SkPaint object
• flutter::Canvas calls ask flutter::Paint to sync the Dart attributes for a given Op
• DL canvas unit tests use the data to verify when to expect the pixels to change when we render with a given Op with a given attribute

[gw280]

Is this the behaviour we actually want? It seems more intuitive to me that if we pass an invalid sigma we error out and don't alter the state of the DisplayList. If we're doing this, please can we explicitly document this behaviour somewhere?

[flar]

This is the behavior of SkMaskFilter::MakeBlur(). If the sigma fails the tests there, they return nullptr and setting that into the paint resets the mask filter to null.

[flar]

Note that using an SkMaskFilter(..., 0.0) filter has always been equivalent to turning the filter off. That's what was happening in the downstream tests.

[gw280]

LGTM, but please add an API comment here detailing this behaviour.