Conditional visibility - fallback visibility for old SDKs

[JZDesign]

Checklist

• If applicable, unit tests
• If applicable, create follow-up issues for purchases-android and hybrids

Motivation

As we evolve the conditional visibility feature and add new conditions, our users will likely wind up in a spot where their paywalls don't render in an expected way. We need to provide an option to allow them to account for old SDKs and to control how their paywall renders if they use newer conditions that old SDKs are unaware of.

Description

Adds a property to the components that defines how the SDK should handle unsupported conditions

[RevenueCat-Danger-Bot]

	1 Error
🚫	Label the PR using one of the change type labels. If you are not sure which label to use, choose pr:other.

Label	Description
pr:feat	A new feature. Use along with pr:breaking to force a major release.
pr:fix	A bug fix. Use along with pr:force_minor to force a minor release.
pr:other	Other changes. Catch-all for anything that doesn't fit the above categories. Releases that only contain this label will not be released. Use along with pr:force_patch, or pr:force_minor to force a patch or minor release.
pr:RevenueCatUI	Use along any other tag to mark a PR that only contains RevenueCatUI changes
pr:next_release	Preparing a new release
pr:dependencies	Updating a dependency
pr:phc_dependencies	Updating purchases-hybrid-common dependency
pr:changelog_ignore	The PR will not be included in the changelog. This label doesn't determine the type of bump of the version and must be combined with pr:feat, pr:fix or pr:other.

Generated by 🚫 Danger