Build DisplayList directly from flutter::Canvas

[flar]

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

I am marking this as a WIP only until I run some more tests manually (and get the test results from this PR) and look for some potentially dead code. The mechanism should be ready to go other than that.

[flar]

I've rebased to a working engine commit so this PR is now ready for review.

[gw280]

Should we consider using SkMatrix here?

[flar]

Maybe. We use Skia objects in a few places in DL, but I was generally looking to start eliminating them where possible to make the packages somewhat independent. There are tasks in flutter/flutter#85737 that talk about removing or simplifying our dependence on Skia objects.

For matrices, we need to start tracking things with 4x4 matrices everywhere to eliminate the problems with perspective matrix concatenation, but that makes simple operations take more memory and compute time so I was toying with creating our own transform class that will track a 2x3 matrix 99% of the time, and expand to 3x3 or 4x4 only when needed. Then we can rethink issues like these.

[gw280]

nit: can we make these constexpr?

[flar]

I would have to place these in the class, but they are only used for initialization. The kConstants they refer to are private in the Flags class.

[gw280]

should we null out the current_blend_mode_ here?

[flar]

You can't null out an enum value, unfortunately. The rule here is that current_blender_ supersedes current_blend_mode_.

I added doc comments for this.

[gw280]

would it be worth adding a Blender to the BlendMode enum?

[flar]

It's a Skia enum. We'd have to ask them.

[flar]

One issue with that is that someone might call "setBlendMode(kCustom)" and what would we do with that request?

[gw280]

Why is the Builder API using degrees, and the Canvas API using radians?

[flar]

Builder code is building from an SkPicture replacement so it matches SkCanvas rather than ui.Canvas. It is somewhat arbitrary, though.

[gw280]

In general I really like a lot of the refactoring in this PR, especially the new DisplayListFlags class. I just find the way SkCanvas vs. DisplayListCanvasRecorder is handled right now to be very confusing.