feat(secrets)!: replace the signing object with secrets.gpg

The `signing` object was the last Secret-related configuration living outside of the `secrets` section introduced in the
previous commit. Keeping it separate meant that the GPG key Secret was the only one without configurable annotations,
labels and a proper `existingSecret` reference, and users had to learn two different conventions for the same concept.

`signing` is therefore removed and fully replaced by `secrets.gpg`:

  signing.enabled        -> secrets.gpg.enabled
  signing.gpgHome        -> secrets.gpg.new.gpgHome
  signing.privateKey     -> secrets.gpg.new.privateKey
  signing.existingSecret -> secrets.gpg.existingSecret.{enabled,secretName}

`gpgHome` is now stored as a key inside the GPG key Secret and consumed via `secretKeyRef` instead of being rendered as
a plain environment variable value. This keeps the whole GPG configuration in a single object, so an operator can hand
over one Secret that fully describes the signing setup instead of splitting it across values and Secret data. The key
names of an externally provided Secret are configurable via `secrets.gpg.existingSecret.gpgHomeKey` and
`secrets.gpg.existingSecret.privateKeyKey`, because chart-defined key names cannot be assumed for Secrets that are
managed by an external system such as an operator or a secret store.

To avoid silently ignoring a now unknown value, `deprecation.yaml` fails the render when `signing` is still set and
points to `secrets.gpg`. As with the other deprecation guards it can be bypassed via `checkDeprecation: false`.

The unit tests are migrated accordingly and the `GNUPGHOME` assertions now verify the `secretKeyRef` shape. Two new
cases cover custom `gpgHomeKey` and `privateKeyKey` values of an existing Secret.

The README gains a `To 13.0.0` upgrade section documenting this change together with the `secrets.*` block and the
Secret renames of the preceding commits.

BREAKING CHANGE: The `signing` object has been removed and is replaced by `secrets.gpg`. Rendering fails if `signing`
is still set. Secrets referenced via `secrets.gpg.existingSecret` now additionally require a `gpgHome` key next to
`privateKey`.

Co-authored-by: Copilot <copilot@github.com>

unittests/helm/init/init_directory_structure.sh-rootless.yaml

@@ -7,8 +7,8 @@ templates:
 tests:
   - it: runs gpg in batch mode
     set:
-      signing.enabled: true
-      signing.privateKey: |-
+      secrets.gpg.enabled: true
+      secrets.gpg.new.privateKey: |-
         -----BEGIN PGP PRIVATE KEY BLOCK-----
         {placeholder}
         -----END PGP PRIVATE KEY BLOCK-----
@@ -37,8 +37,8 @@ tests:
             chmod -v ug+rwx "${GITEA_TEMP}"
   - it: adds gpg script block for enabled signing
     set:
-      signing.enabled: true
-      signing.privateKey: |-
+      secrets.gpg.enabled: true
+      secrets.gpg.new.privateKey: |-
         -----BEGIN PGP PRIVATE KEY BLOCK-----
         {placeholder}
         -----END PGP PRIVATE KEY BLOCK-----

unittests/helm/init/init_directory_structure.sh.yaml

@@ -8,8 +8,8 @@ tests:
   - it: runs gpg in batch mode
     set:
       image.rootless: false
-      signing.enabled: true
-      signing.privateKey: |-
+      secrets.gpg.enabled: true
+      secrets.gpg.new.privateKey: |-
         -----BEGIN PGP PRIVATE KEY BLOCK-----
         {placeholder}
         -----END PGP PRIVATE KEY BLOCK-----
@@ -43,8 +43,8 @@ tests:
   - it: adds gpg script block for enabled signing
     set:
       image.rootless: false
-      signing.enabled: true
-      signing.privateKey: |-
+      secrets.gpg.enabled: true
+      secrets.gpg.new.privateKey: |-
         -----BEGIN PGP PRIVATE KEY BLOCK-----
         {placeholder}
         -----END PGP PRIVATE KEY BLOCK-----