Integrate Workload APIs with Job Controller

This KEP integrates the Workload-aware Scheduling (WAS) APIs (Workload and PodGroup) into the batch/v1 Job by adding a user-facing spec.scheduling field, allowing users to express explicit scheduling intent such as gang scheduling[^1], topology co-location, and disruption policies. The feature has gone through two alpha releases: - v1alpha1 (v1.36) intentionally bypassed a user-facing API: the controller inferred a hardcoded Gang policy from the Job's type (parallel Jobs with indexed completion mode), with minCount fixed to parallelism. - v1alpha2 (v1.37) replaced that automatic, controller-inferred model with an explicit, user-driven design that separates scheduling policy from workload structure. It introduced the spec.scheduling field on the Job API, built on the reusable scheduling building blocks and the shared workloadbuilder translation library defined in [KEP-6089], keeping the Job integration consistent with the rest of the ecosystem rather than reinventing bespoke logic. The Job controller acts as a translator, compiling spec.scheduling into the underlying Workload/PodGroup objects. When spec.scheduling is omitted, it defaults to Basic scheduling, so the scheduling outcome of existing Jobs is preserved. For v1.38 the integration is promoted to Beta and the WorkloadWithJob feature gate is enabled by default. Because the spec.scheduling field is embedded in the GA batch/v1 API, its building blocks graduate straight into scheduling.k8s.io/v1 (with Go type aliases left in v1alpha3) as described in [KEP-6089]. The Beta revision also resolves the design questions the v1alpha2 left open and the controller exposes metrics for the Workload/PodGroup lifecycle. Default enablement is conditional on the GenericWorkload gate ([KEP-4671]) being enabled by default in the same release, since WorkloadWithJob depends on it.