feat(deployment)!: move tolerations to deployment.tolerations

The top-level `tolerations` value only ever configured the pod spec of the Gitea Deployment, but was declared
next to chart-wide settings. Moving it into the `deployment` dict completes the consolidation already done for
`affinity`, `dnsConfig`, `nodeSelector`, `priorityClassName`, `resources` and `topologySpreadConstraints`, so
every pod scheduling setting is now grouped in one predictable place instead of being scattered across the
values file.

A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be dangerous here: the tolerations would be dropped without any warning and the Gitea pod could no longer be
scheduled onto the tainted nodes it was explicitly pinned to, leaving the deployment stuck in `Pending`.

BREAKING CHANGE: `tolerations` no longer exists. Use `deployment.tolerations` instead. Installations that still
set `tolerations` will fail unless `checkDeprecation` is set to `false`.

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

values.yaml

@@ -299,9 +299,6 @@ gatewayAPI:
 ## @param schedulerName Use an alternate scheduler, e.g. "stork"
 schedulerName: ""
 
-## @param tolerations Tolerations for the deployment
-tolerations: []
-
 ## @section deployment
 deployment:
   ## @param deployment.enabled Enable the deployment of Gitea.
@@ -387,6 +384,13 @@ deployment:
   ## @param deployment.terminationGracePeriodSeconds How long to wait until forcefully kill the pod
   terminationGracePeriodSeconds: 60
 
+  ## @param deployment.tolerations Tolerations of the Gitea deployment.
+  tolerations: []
+  # - key: database/type
+  #   operator: Equal
+  #   value: postgres
+  #   effect: NoSchedule
+
   ## @param deployment.topologySpreadConstraints TopologySpreadConstraints for the deployment
   topologySpreadConstraints: []
   # - topologyKey: kubernetes.io/hostname