Proposal: Introduce `WorkflowUICommon`

[dhavalshreyas]

A few container Screen that are currently in Samples, would be better situated with an independent dependency. This will enable easy consumption of these common UI containers.

Containers in Samples currently:

• AlertContainer
• BackStackContainer
• ModalContainer

Possible future additions:

• TabBarScreen #1098
• EquatableScreen - A Screen that updates it's rendering only if it's contents have changed.
• ViewControllerLifecycleObserverScreen - A Screen that has callbacks for some common UIViewController lifecycle events.

Proposal

Move container Screens from Samples to WorkflowUICommon and add WorkflowUICommon.podspec in root. Publish WorkflowUICommon.podspec to Cocoapods.

[AquaGeek]

IIRC, they're in Samples currently because we explicitly don't want them to be added as dependencies elsewhere — they're just guideposts to help others build their own containers. Outside of that, are we willing to take on the maintenance burden of these, given we use parallel implementations internally?

[AquaGeek]

One of the suggestions @bencochran brought up internally was the option of us publishing the structs for these Screens (instead of both the struct and the UIViewController) and allowing folks to add the conformance to Screen themselves (BYO view controller). That would at least let us close the gaps between these samples and our own internal versions.

[zach-klippenstein]

I believe this is the approach we're currently using in kotlin.