Implement etcd proxy certificates regeneration mechanism

[xmudrii]

In #46 we're implementing the CA for generating certificates for the etcd-proxy.

As decided, the initial implementation is not going to implement the mechanism for regenerating certificates, in order to make it easier to review and ship changes.

The implementation could happen in three stages:

• Implement mechanism for checking are certificates in-place and valid. It is up to be discussed how exactly are we going to check this. Potentially, we could put expiry date in an annotation, but we could also check several more things, such are hosts valid.
• Implement mechanism for regenerating certificates. If certificates are not in-place or not valid, we want to regenerate them. This could require an architectural change: we want to save to save the signer keys, so we can sign new certificates. Currently, signer keys are discarded as we don't regenerate certificates. I think saving them in EtcdProxyController namespace is enough. It's up to be decided do we want to save keys in a new Secret, or we want to reuse the Secret we already have for etcd-proxy server certificate and key.
• Implement certificate rotation. See Make API Server handle etcd certificates rotation #49 for more details.

/cc @sttts @deads2k

[xmudrii]

Part 1 — initial CA implementation: #46
Part 2 — utility functions for CA renewal: #57