Create an extension on WorkflowHost for running a workflow and just getting its outputs

[zach-klippenstein]

I have seen a few uses of flatMapWorkflow where only the OutputTs are needed. This is easy to pull into an extension on WorkflowHost that doesn't have all the same problems as flatMapWorkflow (see #377).

[zach-klippenstein]

Prototyping internally first, to make sure it solves the right problems.

API looks like:

/**
 * Returns a [ConnectableFlowable] that, when connected, will subscribe to [inputs], starts [workflow],
 * and emits all outputs emitted by the workflow. Renderings and snapshots are dropped. The workflow
 * will not start until [inputs] emits its first value.
 *
 * Outputs will be multicasted to all subscribers (i.e. the returned [Flowable] is
 * [published][Flowable.publish].
 *
 * The workflow will be executed on the dispatcher configured on this [WorkflowHost.Factory].
 *
 * @param snapshot If non-null, used to restore [workflow].
 * @return A [ConnectableFlowable] that will multicast to all subscribers (i.e. is
 * [published][Flowable.publish]) when connected. Nothing will be emitted until connection. Disposing
 * the connection and re-connecting will discard any state and restart the workflow runtime, again
 * restoring from [snapshot] if non-null.
 */
fun <InputT, OutputT : Any> WorkflowHost.Factory.runOutputs(
  workflow: Workflow<InputT, OutputT, *>,
  inputs: Flowable<out InputT>,
  snapshot: Snapshot? = null
): ConnectableFlowable<out OutputT> = TODO()

Returns a disconnected ConnectableFlowable to force multicasting (whenever I've seen code that calls ReceiveChannel.asObservable, I and everyone else forgets to multicast it) but still allow the caller to control the upstream subscription. Callers are expected to be managing their own lifetime and thus be able to own the connection.

cc @rjrjr @davidapgar @timdonnelly

[zach-klippenstein]

This will depend on converting WorkflowHost to be two-output. I can do this with channels now, or just use Flow once #409 lands. I'm tempted to do the latter, since both are experimental anyway and Flow is really the best way to express this API.

[zach-klippenstein]

I don't have a use case for this that isn't easy to do with the new launchWorkflowIn API. Closing.