Pod networking ready condition

<!-- 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 --> Readiness to start the containers in a pod, marked by successful pod sandbox creation, is a critical phase in a pod's lifecycle that the kubelet orchestrates across multiple components: in-tree volume plugins (ConfigMap, Secret, EmptyDir, etc), CSI plugins and container runtime (which in turn invokes a runtime handler and CNI plugins). Completion of all these phases puts the pod sandbox in a state where the containers in a pod can be started. This KEP proposes a PodReadyToStartContainers condition in pod status to indicate a pod has reached a state where it's containers are ready to be started. The PodReadyToStartContainers condition will mark an important milestone in the pod's lifecycle similar to ContainersReady and the overall Ready conditions in pod status today. An alternate name like SandboxReady is avoided since Kubernetes does not directly surface low level sandbox related concepts to all users.