1311:Use Compose's AndroidUiDispatcher.Main to conflate actions in runtime.

[steve-the-edwards]

Note this also includes some adjustments to the runtime loop. After the first suspension to wait and apply an action, with CONFLATE_STALE_RENDERINGS we loop without suspending - applying any actions that are already queued up on the action queues.

If it is not being used on Android, use it for the runtime whenever on Android (requiring Compose).

As it turns out, Compose's AndroidUiDispatcher.Main and its greedy behaviour to drain all dispatches before the next Android Choreographer frame gives us exactly the behaviour we want.

In fact, CONFLATE_STALE_RENDERINGS is basically a no-op when using the AndroidUiDispatcher.Main to dispatch the runtime and consume the renderings. The greediness means that the updates all happen before the rendering can be consumed by view code (as well as all happen before the next frame). Because this is not an immediate dispatcher, when we pass a new rendering to the stateflow to be consumed by the view code, it is not immediately picked up (it has to be dispatched, even though the AndroidUiDispatcher.Main is going to do that greedily and before the next frame). This changes ordering.

On Android context where we use this dispatcher, we can likely just not use CONFLATE_STALE_RENDERINGS at all. however, for other dispatchers, it could still have an effect. We will want to be careful with how we roll out this change.

Still the code used to drain immediately available actions can be used by DRAIN_EXCLUSIVE_ACTIONS to avoid render passes.

Fixes #1311

This should also take care of #1257 if we start using the Compose AndroidUiDispatcher.

[CLAassistant]

All committers have signed the CLA.