Automatic merge from submit-queue (batch tested with PRs 39280, 37350, 39389, 39390, 39313)

Refactor the certificate and kubeconfig code in the kubeadm binary into two phases

**What this PR does / why we need it**:

First stab at refactoring kubeadm code into logically independent phases.
This defines two phases in the kubeadm init process:
 - certs: Takes some API values as input (the API will be refactored in a later PR), and generates certificates in the pki directory
 - kubeconfig: Takes the pki directory and the endpoint where the master is located and produces two kubeconfig files: admin.conf and kubelet.conf

**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*:
Required long-term for graduating our API

**Special notes for your reviewer**:

### Old sample output
The earlier kubeconfig code had a bug in it; see this example:
_admin.conf:_
```yaml
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <data>
    server: https://192.168.200.x:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: admin
  name: admin@kubernetes
- context:
    cluster: kubernetes
    user: kubelet
  name: kubelet@kubernetes
current-context: admin@kubernetes
kind: Config
preferences: {}
users:
- name: admin
  user:
    client-certificate-data: <data>
    client-key-data: <data>
- name: kubelet
  user:
    client-certificate-data: <data>
    client-key-data: <data>
```
kubelet.conf:
```yaml
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <data>
    server: https://192.168.200.x:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: admin
  name: admin@kubernetes
- context:
    cluster: kubernetes
    user: kubelet
  name: kubelet@kubernetes
current-context: admin@kubernetes
kind: Config
preferences: {}
users:
- name: admin
  user:
    client-certificate-data: <data>
    client-key-data: <data>
- name: kubelet
  user:
    client-certificate-data: <data>
    client-key-data: <data>
```
```console
$ shasum /etc/kubernetes/*.conf
2b22b25cc4c97e5619ece6c43badf42b87c4970a  /etc/kubernetes/admin.conf
2b22b25cc4c97e5619ece6c43badf42b87c4970a  /etc/kubernetes/kubelet.conf
```

#### New output
admin.conf
```yaml
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <data>
    server: https://192.168.200.x:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: admin
  name: admin@kubernetes
current-context: admin@kubernetes
kind: Config
preferences: {}
users:
- name: admin
  user:
    client-certificate-data: <data>
    client-key-data: <data>
```
kubelet.conf
```yaml
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <data>
    server: https://192.168.200.x:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubelet
  name: kubelet@kubernetes
current-context: kubelet@kubernetes
kind: Config
preferences: {}
users:
- name: kubelet
  user:
    client-certificate-data: <data>
    client-key-data: <data>
```

**Release note**:

```release-note
Refactor the certificate and kubeconfig code in the kubeadm binary into two phases
```

PTAL @dgoodwin @jbeda @mikedanese @errordeveloper @pipejakob @lukemarsden