Add Recreate Update Strategy to StatefulSet

StatefulSets currently offer two update strategies: OnDelete (manual) and RollingUpdate (automatic, default). When using RollingUpdate with the default podManagementPolicy: OrderedReady, StatefulSets follow sequential ordering where each individual pod must be Running and Ready before the controller proceeds to update the next pod. Even with the maxUnavailable option (which allows multiple pods to be updated simultaneously), the controller still requires each pod to reach Ready state before moving forward but stuck pods halt the entire update process. While podManagementPolicy: Parallel allows pods to be updated simultaneously without waiting for Ready state, stuck pods remain and are not automatically replaced. This design ensures data safety for stateful workloads but creates a critical operational problem. When a StatefulSet update results in pods that fail to reach Ready state (due to configuration errors, resource constraints, etc..), the rolling update process becomes permanently stuck. Even after applying a corrected configuration, the controller will not automatically replace the broken pods, requiring manual intervention to delete stuck pods. This behavior has generated significant user frustration across multiple GitHub issues (#67250, #60164, #109597) with users reporting: - Broken CI/CD pipelines requiring manual intervention - Inability to automatically recover from configuration mistakes - Operational burden in managing stateful applications This KEP proposes adding a new Recreate update strategy to StatefulSets, mirroring the behavior of Deployments' Recreate strategy. This strategy deletes all pods, waits for full termination, then creates new pods according to podManagementPolicy. This provides a simple, predictable way to handle stuck pods and enables automa