Encrypt with multiple public keys (disaster recovery, ...)

## Proposal

Teach `kubeseal` to emit multiple versions of the same encrypted item, each one encrypted with a different cert.

## Rationale

There are two major use cases:

1. disaster recovery
2. multi-cluster / multi-env

### Disaster recovery

Since the introduction of automatic key renewal in #137, the process around disaster recovery become more complex since now users have to back up the sealing keys matching the label `sealedsecrets.bitnami.com/sealed-secrets-key=active` relatively frequently. If the cluster blows up after a new key has been created and before a backup has happened, all recently sealed secrets will be effectively lost.

If `kubeseal` can seal with multiple certificates, users could have a "backup key pair", whose private key is securely stored in a (physical?) vault and used only during

Decoupling the disaster recovery procedure from the creation of new sealing keys will allow us to explore more interesting patterns. For example, we could create a new private key per namespace, or even a new private key for each sealed secret! The trade-off between online/offline sealing still remains, but removing the disaster recovery process makes it more palatable to explore operation modes that involve multiple secrets created at arbitrary cadences.

### Multi-cluster / multi-env

Ideally secret should be as fine grained as possible in order to reduce the impact of a leak and subsequent secret revocation. E.g. if you need a slack API key in a bunch of applications, possibly running in different clusters, it's better to create a token for each application and seal it independently.

That said, in some cases that's not practical or perhaps not even possible and you end up sealing the same underlying secret into multiple sealed secrets (or using cluster-wide scope if applicable)

Instead of scattering around each of those sealed secrets in independent files, we could use the "multi-encryption" feature to have a single sealed secret that seals the same items for N target environments (either different namespaces of the same cluster or even different clusters altogether)

# References

* #120
* #226