Workflows started with setContentWorkflow may drop early output emissions.

[rjrjr]

I'm not thrilled with this extension method any more, but have no change to suggest for this PR. I'll follow up after you merge.

Originally posted by @rjrjr in #426

[rjrjr]

More thoughts on this:

• Worst problem is it's difficult / impossible to receive all output events when you're setting things up from onCreate in an Activity or Fragment
• Surprising that setContentWorkflow() now returns an object whose start() method must be called. Should just drop the extensions, they're too clever.
• Confusing that workflow is provided on every call to setContentWorkflow. It's only needed the first time, should make that a factory lambda

[zach-klippenstein]

This issue name is obsolete: WorkflowRunner no longer has a start method, it starts the workflow host lazily when one of the outputs is subscribed to, like it did before.

As for outputs, we should hook into the lifecycle of whatever is creating/retrieving the workflow runner (activity or fragment) and either buffer or pause (via backpressure) the emission of outputs when the lifecycle owner isn't active. And since that caller will be subscribing to outputs from an activity or component, the subscription will likely close over that object and we should be careful to not invoke it in a bad state.

[zach-klippenstein]

I updated the issue name so we can remove from the 0.18 milestone.

[rjrjr]

As part of the discussion behind #439, we're realizing that this is a pretty easy (and natural) problem for WorkflowRunner to solve. It's job is to ensure that outputs are buffered until someone is subscribed to receive them.

At the same time, we should probably replace its rendering and outputs Rx Observables with LiveData properties.