Mutable Node Scheduling Directives for 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 queue controller may also want to control on which group of nodes a job should run. For example, it may want to send the job to a specific partition (e.g., preemptibles) or a specific location (e.g., zone x). This is a proposal to relax update validation on jobs that have never been unsuspended to allow mutating node scheduling directives, namely the pod template's node affinity, node selector, tolerations, schedulingGates, annotations and labels of the job's pod template. This enables a higher-level queue controller to inject such directives before un-suspending a job to influence its placement. <!-- This section is incredibly important for producing high-quality, user-focused documentation such as release notes or a development roadmap. It should be possible to collect this information before implementation begins, in order to avoid requiring implementors to split their attention between writing release notes and implementing the feature itself. KEP editors and SIG Docs should help to ensure that the tone and content of the Summary section is useful for a wide audience. A good summary is probably at least a paragraph in length. Both in this section and below, follow the guidelines of the [documentation style guide]. In particular, wrap lines to a reasonable length, to make it easier for reviewers to cite specific portions, and to minimize diff churn on updates. [documentation style guide]: https://github.com/kubernetes/community/blob/master/contributors/guide/style-guide.md -->