Simplify `flow`

[dnfield]

In particular, PaintContext and PrerollContext are both pretty complicated structs with mutually incompatible raw pointer fields (and sometimes duplicated fields).

We should do what we can to simplify this.

/cc @flar

[jonahwilliams]

At some point in the future, we'll be compiling at least some engine configurations with Impeller only. In an Impeller only world, flow could be much simplified, or even removed by delegating more of the work directly into the renderer. Even the design of having multiple differrent kinds of compositing nodes may not make sense - perhaps a generic Picture/PlatformView/SaveLayer node design would be better?

[flar]

Or eliminate flow entirely.

Right now the only reason an engine layer exists is because some widget/RenderObject somewhere in the tree said "I can't draw my stuff" and all parents suddenly stopped being able to specify most of what they wanted to appear in a Picture.

The more we can eliminate these exceptions, the fewer cases of duplicate rendering code (one path in the RO and one in a flow layer) we'll have.

For example, RepaintBoundaries don't need to fracture the scene just to reuse their sub-trees - the sub-trees can be turned into pictures and rendered with drawPicture.

[flar]

We couldn't teach SkPicture to understand our "draw something Flutter-specific" cases so we created flow. Now that we have DL and Impeller Pictures, we can have them accept these special "somethings" as part of a Picture/scene because it is our own code.

[jonahwilliams]

I'm always down for having fewer compositors

[chinmaygarde]

xref https://github.com/flutter/flutter/issues/134759