Proposal: Support compose on the desktop

[zach-klippenstein]

There is already some code in the compose repo to support running compose in desktop Swing apps (eg). It does not appear that any artifacts for this have been released publicly at the time of writing, but once they are, it would be interesting for this library to support desktop use.

To that end, the main artifact should be split in two: one that contains android-specific pieces (anything to do with Views) and one that is generic (eg ComposeWorkflow, WorkflowContainer).

ViewEnvironment

ViewEnvironment is ultimately a generic, self-contained concept without Android dependencies, but in practice the API effectively has a hard dependency on Android Views for safety and convenience since there's no other use case for it in the core library. It might be better for this library to divorce completely from relying on it. Inside a purely Compose app, ambients can solve all the use cases of ViewEnvironment, so I don't think we even need to design/build a replacement. The bindCompose lambda would change to just accept a rendering. The downside of this approach for the Android-specific Compose/Workflow integration is that it reverts the very intentional decision to expose ViewEnvironment explicitly instead of hiding it in an Ambient, but perhaps the benefit of looser coupling to Android APIs is worth the risk. The existing bindCompose could be built in the Android-specific module if necessary.

That said, if we did want to keep the ViewEnvironment dependency in the common module, it would depend on https://github.com/square/workflow/issues/1160.

ViewRegistry

It's not clear that a ViewRegistry concept would even be necessary in a completely Composable app, so it's probably best to not design or build one until it's clear there's a concrete use case.

But just to jot down some thoughts: an independent ComposableFactory<R> could be a clone of ViewFactory<R> that has a @Composable render(R) method instead of buildView(). bindCompose() returns a ComposableFactory. There's a ComposableFactory<R>.asViewFactory(): ViewFactory<R> that returns ComposableViewFactory which now implements both ComposableFactory and ViewFactory, and fast-path logic in showRendering looks for ComposeFactorys instead. ComposeViewFactory would be responsible for adapting the Android ViewEnvironment to whatever solution we'd end up going with for the common module (either a generic ViewEnvironment or something with ambients).