Fine grained SupplementalGroups control

The KEP seeks to provide a way to choose correct behavior with how Container Runtimes (Containerd and CRI-O) are applying SupplementalGroups to the first container processes. The KEP describes the work needed to be done in Kubernetes or connected projects to make sure customers have a clear migration path - including detection and safe upgrade - if any of their workflows took a dependency on this arguably erroneous behavior. ### The issue How supplemental groups attached to the container processes are defined in two levels in Kubernetes, one is OCI image level and the other is Kubernetes API level. In OCI image spec, config.User OCI image configuration(mirrored spec of USER directive in Dockerfile) is defined as follows: > The username or UID which is a platform-specific structure that allows specific control over which user the process run as. This acts as a default value to use when the value is not specified when creating a container. For Linux based systems, all of the following are valid: user, uid, user:group, uid:gid, uid:group, user:gid. If group/gid is not specified, the default group and supplementary groups of the given user/uid in /etc/passwd from the container are applied. In Kubernetes API level, PodSecurityContext.{RunAsUser, RunAsGroup, SupplementalGroups} relates to this. This API was designed to override config.User configuration of OCI images. However, in the current implementation, as described in kubernetes/kubernetes#112879, even when a manifest defines both RunAsGroup, group memberships defined in the container image for the UID are attached to the container process (see the [the next section](#steps-