Consider responsibility split for Widget.Children

[JakeWharton]

The responsibility of this type has grown from its original three callbacks which map fundamentally to the underlying Compose Applier.

Things that are going on:

• Ownership of the target native view tree container
• Interaction with the native view tree container for insert, removal, and moves
• Ownership of the list of Widgets, mostly to provide Modifier access
• Callbacks for when Modifiers change on a Widget

Can we split this up?

I'd like to see ownership of the native container and interaction as a separate thing. This means we can replace a native view instance without ever notifying the parent, for example, if unscoped modifiers and their interceptors dictate such an event should happen.

Can we get away with eliminating the list of widgets for a list of Modifiers? And then a callback when the modifiers change (either the initial value, or subsequent changes).

Need to land unscoped modifiers first before this, but they would benefit greatly from it.