[WIP] Make helm charts respect namespace parameter

[lblackstone]

Fixes #217

[lblackstone]

Hmm, looks like I'm not handling the namespacing properly for CRDs. Will fix that and retry.

[hausdorff]

I'm not completely sure that I fully understand the implications of this change. Because this change is fairly risky, I think it's worth asking a few "dumb" questions just to make sure we're all on the same page.

• Does auto-adding and then stripping the namespace affect how the resource ID is allocated? If so, is it possible that this will trigger replaces for existing stacks that use namespace or set namespace from the transformations API?
• Does this changing of the resource definitions match what the customers expect? i.e., if namespace is automatically populated in the diff view, will it confuse users?

You can also imagine packing the namespace as a separate field into the properties, which already contains both the old inputs and the new inputs. Philosophically this is closer to what kubectl --namespace and helm --namespace do -- the --namespace flag does not change the resource definition, but instead, changes the namespace component of the POST request route.

It's hard to say whether that approach is better, since then you'd have to incorporate that logic into (e.g.) Diff. For me the main question I don't know is: which of these things does the user expect, and which of these things has a smaller chance of breaking in visible ways?

[lblackstone]

This approach is not working out for CRs.

The problem is that the required CRD is often unregistered at the Check stage, so the provider is unable to determine if the resource is namespaceable. This can only be determined after the CRD is created. Unfortunately, this doesn't work cleanly with the preview and resource naming logic, which doesn't have access to an official source of truth.

This leads to two conclusions:

1. We should pass the namespace in the provider opts as @hausdorff suggested rather than putting it in the object spec since this affects previews.
2. We should decouple the resource names from the namespace since we can't reliably determine that information prior to creation.

I'm going to rework this and revert #506 in the meantime since it relies on the same faulty assumptions.