This PR offers essentially identical performance for animated transforms to a prior PR (#21943) but uses a different mechanism to trigger the performance tradeoff. Please read the description of that PR for an overall description of the problem and the benefits of having the caching being performed by the Transform layers themselves.

These engine changes will eventually enable fixing flutter/flutter#24627

An additional PR for the Framework repo will be required to use these changes, but the new property I added here should be backwards compatible to existing Frameworks as it defaults to the compatibility value (TransformMethod.render).

In this solution a "method" hint is added to the transform layers to indicate whether they should use the transform for rendering the child, or to transform the bitmap representation of the child.

See the TransformMethod enums (one in Dart and one in C++) for the reference for the API. I would especially like feedback on the naming of the enum and its values. This is logically similar to the Clip enum used for the clipBehavior properties of the clip layers in that it suggest how to apply the operation. I'll note that I never liked the name Clip for the behavior enum for the clipping since it sounds like it is a definition of the clip rather than a suggestion on how to apply it. In this case, it would be inappropriate to name this new enum Transform since that is identical to the name of the widget where it will be used, so the naming had to diverge from the Clip model.

In the previous PR, the developer could specify a custom transform for caching the child, but in this PR the transform for caching will always be the transform inherited from the ancestor layers. The developer can still achieve control over the transform that the child is cached with by decomposing the transform being animated into a static part applied to the child, and a dynamic part applied as a bitmap to the statically transformed child by nesting two transform layers and only applying the bitmap hint to the outer transform. That nesting technique will not likely be used often except for cases like animating a scale from A to B where the developer may want to cache the child at the larger of (A,B) and then have the outer animating transform be the ratio difference (animating from A/B->1.0, or 1.0->B/A).

The performance is nearly identical to the previous PR, but it seems that I more often get lucky and have the performance of the "cached Transform" animation be closer to ~6.5ms, though the difference is within the margin of error since if I play with the test app for a bit, then sometimes it will perform closer to the ~7ms that I saw with the prior solution. I don't think this is significant other than to point out that this solution performs no worse than the previous solution. If it really is better in the long run, then that would have to be established by collecting benchmark data over time.

Since the API has changed, there is a new test app required which can be seen at this gist: https://gist.github.com/flar/41dbec4b5a610c61c40fa77ce2156b56