ClusterSecret shim by fan-out

**Background**

Secrets are naturally scoped in the namespace where they live and you cannot reference them from other namespaces (by design, see rejected proposal https://github.com/kubernetes/kubernetes/issues/57325).

But that's annoying for some kind of secrets like `kubernetes.io/dockerconfigjson` that in many scenarios need to be copied into many (or every?) namespace. For example consider you have a cluster where you want everybody using it access your company internal registry.

There is an interesting proposal upstream in https://github.com/kubernetes/kubernetes/issues/70147 for a `ClusterSecret` primitive.
It's not clear if it's ever going to be accepted, but it's clear that this issue is hitting a nerve.

The proposed workarounds are either not applicable in many common managed clusters (see https://github.com/kubernetes/kubernetes/issues/70147#issuecomment-478120269) or require a controller that will basically copy secrets around (as opposed to have this feature built in k8s).

In our #sealed-secrets slack channel, a user has mentioned https://github.com/mittwald/kubernetes-replicator as one of such controllers.

Here we'll explore a possibility to make sealed-secret support this case directly,
although I'm still not sure whether this belongs here.
There is thin line bloating monoliths and excessive fragmentation, but perhaps it makes more sense if we think of this as a shim for future secret "type" (although whether that secret type will actually exist is just a bet) rather than a generic secret copying primitive.

**Proposal**

Let's pretend https://github.com/kubernetes/kubernetes/issues/70147 gets accepted and implemented at some point in the future.

For sealed-secrets users to leverage this new feature, we need a way to encode which kind of output resource it needs to produce, i.e. a `Secret` or a `ClusterSecret`.

```
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
creationTimestamp: null
name: private-docker-registry
spec:
encryptedData:
.dockercfg: ...
template:
kind: ClusterSecret # <---- new field
type: kubernetes.io/dockercfg
metadata:
name: private-docker-registry
```

Until ClusterSecret gets supported for real, sealed-secrets would fake it: it would literally create (update and delete) a secret object in every namespace (and also react to creation of new namespaces).
If ever the ClusterSecret feature gets implemented natively, the sealed-secret controller would just create that object type natively.

I suggest we don't add support for any filtering feature (on namespace names, or via matchLabels etc) until this aspect of ClusterSecret gets fleshed out more upstream.

This will effectively limit the use for "pan cluster" secrets only to secrets which are inherently safe to be used that way and discourage users from using this feature on secrets that would pose more serious problems if made accessible by all namespaces. I _think_ this follows the spirit of caution around cluster wide secrets in the upstream discussion.

Thoughts?

Start by reading the proposal and the linked Kubernetes issues, especially the discussion of ClusterSecret semantics and namespace behavior. No implementation files or tests are named; done would require an agreed design for the SealedSecret field, fan-out lifecycle, and eventual native ClusterSecret support.

Written by the indexing model from the issue text.