Mutable Pod Resources for Suspended Jobs

In #2232 we added a new flag to allow suspending jobs to control when the Pods of a Job get created by controller-manager. This was proposed as a primitive to allow a higher-level queue controller to implement job queuing: the queue controller unsuspends the job when resources become available. To complement the above capability, a secondary controller may also want to control the resource requirements of a job based on current cluster capacity or resource availability. For example, it may want to adjust CPU, memory, and GPU requests/limits based on available node capacity, allocate specific extended resources like TPUs or FPGAs, optimize resource allocation for better cluster utilization, or modify resource requirements based on queue priority and cluster load. This is a proposal to relax update validation on suspended jobs to allow mutating resource specifications in the job's pod template, specifically CPU, memory, GPU, other extended resource requests and limits, and container references to resource claims. This enables a higher-level controller to optimize resource allocation before un-suspending a job based on current cluster conditions and resource availability.