Add a value to the generated secret that allows a client to check that the sealed secret was actually decrypted successfully

**Which component**:
controller: registry.gitlab.com/bkkvbu/platform/sealed-secrets/controller:v0.15.0

**Is your feature request related to a problem? Please describe.**
There are basically two use cases that trigger this request:

- We've had several cases where an update to a sealed secret was / could not be not decrypted correctly. This was hard to debug, because it was basically only detectable by looking at the log output of the sealed secret controller.
- We've had several instances where an old version of the secret was used because the new version wasn't yet decrypted.

**Describe the solution you'd like**
I would like to have the `generation` and / or `resourceVersion` of the sealed secret be part of the `ownerReferences`. That way it is easy to check wether the decryption worked as expected and it is also actually possible to wait for the `sealed secret`to be decrypted to a `secret`.

**Describe alternatives you've considered**
We're currently using code like this to work around this problem:

```shell
#!/usr/bin/env bash

ns="--namespace cattle-monitoring-system"

next_generation=$(
kubectl get $ns -oyaml \
sealedsecret rancher-monitoring-grafana-admin \
| yq '.metadata.generation + 1 // 0'
)
yq ".spec.template.metadata.annotations.SealedSecretGeneration=\"$next_generation\"" \
sealedsecret.yml | sponge sealedsecret.yml

# Install sealed secret
kubectl $ns apply -f sealedsecret.yml

# wait for secret to be updated
function generation_from_secret() {
kubectl get $ns -oyaml secret rancher-monitoring-grafana-admin | yq .metadata.annotations.SealedSecretGeneration
}

while [[ "$(generation_from_secret)" != "$next_generation" ]] ; do
sleep 1
done
# install rancher-monitoring helm chart
helm diff upgrade $ns rancher-monitoring rancher/rancher-monitoring --version 102.0.0+up40.1.2 -f values-dev.yaml --allow-unreleased
# helm install $ns rancher/rancher-monitoring --version 102.0.0+up40.1.2 -f values.yaml
```

While this works, it is clunky and hard to extend to all our projects. Also its not easily feasible to extend tools like helm to be able to wait for the secret to update without this being natively supported (AFAIK).

Start with the Kubernetes controller component and review how it creates the generated Secret and its ownerReferences. Compare the available generation or resourceVersion information from the SealedSecret with the requested metadata, and define completion as exposing a reliable source-version value that clients can use to detect successful decryption and wait for updates.

Written by the indexing model from the issue text.