Add clarity around template Secret fields (#1456)

**Description of the change**

A documentation-only change making it clear which fields in the template
`Secret` are directly copied, which undergo processing, and which are
ignored.

This addresses the confusion in issue #1445.

**Benefits**

Clarity for users experimenting with the Secret templating options. The
idea that `.spec.template.data` can be used is apparent as it is
generated by `kubeseal` (defaulting to `null`), but the README does not
make the usage or use-case clear.

**Possible drawbacks**

This change highlights increases the amount of technical detail in the
README that is not relevant to most users.
It also increases the attention drawn to the data templating feature
which could cause requests for changes in that code's scope.

**Alternatives**

Implementation details on the templating logic could be moved into their
own file within `docs/`.

**Applicable issues**

- fixes #1445

---------

Signed-off-by: Benedict Harcourt <ben.harcourt@harcourtprogramming.co.uk>
Signed-off-by: Alejandro Moreno <amorenoc@vmware.com>
Co-authored-by: Alejandro Moreno <amorenoc@vmware.com>

README.md

@@ -116,7 +116,9 @@ In particular, the annotations and labels of a `SealedSecret` resource are not t
 
 To capture this distinction, the `SealedSecret` object has a `template` section which encodes all the fields you want the controller to put in the unsealed `Secret`.
 
-This includes metadata such as labels or annotations, but also things like `type` and `immutable` fields of the secret.
+The `metadata` block is copied as is (the `ownerReference` field will be updated [unless disabled](#seal-secret-which-can-skip-set-owner-references)).
+
+Other secret fields are handled individually. The `type` and `immutable` fields are copied, and the `data` field can be used to [template complex values](docs/examples/config-template) on the `Secret`. All other fields are currently ignored.
 
 ```yaml
 apiVersion: bitnami.com/v1alpha1