Add skipAwait for Helm and YAML SDKs

[lukehoban]

We should consider a global kubernetes:skipAwait setting to turn off all await logic for this package, providing an experience closer to the default Kubernetes API experience. This has significant downsides (outputs not populated, incorrect deployments not identified, etc.), but for many use cases is the initially "expected" behaviour.

We have support for individual resource-level skipAwait annotations today, but not a global setting.

We could also consider support for skipAwait on YAML and Helm components. It's common to want to not await readiness on Helm charts, and is hard to do currently (requires a transformation to add the skipAwait annotation to every child resource).

[lblackstone]

An alternative was proposed where we instead default await logic to warn rather than error on failure. In this case, we'd likely want to have a flag to opt into the current behavior for the CI use case where users may want to error rather than proceeding to any subsequent release steps.

[maxromanovsky]

Well... lack of skipAwait for Helm chart itself (which IMHO should support it natively in Pulumi as it's kind of first class citizen) prevents from quickly experimenting with charts. And typically charts are thirdparty resources, and while adopting/upgrading them it's crucial to fail quickly, then fix-deploy-repeat

[lblackstone]

An alternative was proposed where we instead default await logic to warn rather than error on failure.

I realized that changing the error to a warning has implications for resource dependencies. If the resource isn't actually ready yet, property values may not have been populated yet when downstream resources access them. Since this could lead to a lot of subtle bugs, I think it's better to provide a flag to selectively disable the await logic.

Actually, I'm not sure a provider-level flag makes sense because of this issue. Skipping await logic on a stack that uses resource outputs to populate other inputs can't be expected to work reliably. Providing that option for Helm and YAML specifically makes more sense because these component resource types are generally expected to be self contained (i.e., the resources should eventually resolve after they are created with no expectation of ordering).