What seems to be the problem?

Hello friends! This is related to #703 .

I am working on making a stack that creates portable wordpress workloads. I'll refer to the set of resources created by the stack as the resource bundle or bundle. The current combination of required strongly typed classRefs for claims and namespace-specific defaults is making things a bit trickier than they were before. I'll explain.

The goal is to create a stack which will create a portable resource bundle for the user. I'll define a portable resource bundle as a resource bundle which is decoupled from the details of cloud provider configuration, and which can be used with multiple different cloud provider configurations (potentially one configuration at a time) without modification.

The old way

Before, I was using classRefs and no defaults, and was able to create a resource bundle for a portable workload. To get a workload running, here are what the steps were, roughly:

1. Create a ResourceClass for the dependencies (MySQL and Kubernetes)
2. In the workload, use the names and namespaces for the resource classes in the classRef field.
3. Create all the resources for the resource bundle
4. For portability, keep the bundle the same, but change or create the resource classes to use a different cloud provider

The new way

Here is what it is now:

1. Create strongly typed resource classes for the dependencies
2. In the workload, use strongly typed references in the classRef field, which includes the cloud provider for each of the dependencies
3. Create all of the resources for the resource bundle
4. For portability, create resource classes which use different cloud providers for the dependencies
5. For portability, change the workload to use the new resource classes (because the kind will be different and needs to be updated in the workload)

Now that the workload needs to be edited if the cloud provider changes, I would consider the workload to no longer be portable.

So, what does a portable resource bundle look like today? Here are the rough steps:

1. Create strongly types resource classes for the dependencies
2. Create the namespace N that the bundle's resources will be in
3. Create default resource policies, using namespace N
4. Create the bundle's resources (in namespace N so they bind with the default resource policies)
5. For portability, use different default resource policies, either in namespace N or another namespace

This works, but is also not ideal, because:

• The namespace needs to be created before the default is created.
• Only one default can be active at a time.

If only one default can be active at a time, the default policies should not be part of a portable resource bundle. If the default policies are not part of the resource bundle, the namespace must be created outside of the resource bundle too. This doesn't seem as nice as how it was before, where the bundle could create its own namespace as needed and the user didn't need to worry about creating the namespace ahead of time.

How can Crossplane help?

The proposal would be that we support loosely defined classRefs, which
only use the namespace and name to match (similar to what was happening
before strongly-typed resource classes). Benefits include:

• We can support portable resource bundles without requiring that the
  namespace is created outside of the resource bundle
• We can support multiple different portable configurations for the same
  claim type; for example, a resource bundle could depend on a MySQL
  instance in cloud provider A, and also depend on a MySQL instance in
  cloud provider B. It is not possible to do this in a portable way
  currently.

Here is an example of what a claim could look like in the proposed form:

apiVersion: database.crossplane.io/v1alpha1
kind: MySQLInstance
metadata:
  name: wordpress-mysql-instance
  namespace: wordpresses
  labels:
    stack: sample-stack-wordpress
spec:
  classRef:
    name: standard-mysql
    namespace: crossplane-system
  engineVersion: "5.7"
  writeConnectionSecretToRef:
    name: sql-secret