Secure internal communication with TLS

With #29 TLS, all communication external to the cluster is secured with TLS. However, there still are routes *internal* to the cluster that are unencrypted. These include:

- The web proxy api route (typically localhost only)
- The scheduler proxy api route (typically localhost only)
- The individual cluster api routes

We should be able to secure these automatically by minting temporary credentials to use for each (as we're already doing for the schedulers). The trick here will be distributing these in a secure way. I propose the following:

- If a proxy is managed by the gateway, we mint a temporary credential stored in the gateway's temporary directory for it.
- For proxies managed separately, we add a CLI command `generate-certificate` which outputs a certificate/key pair using the internal CA. A configuration option for setting the internal CA and persisting it somewhere must be present for this to work. The proxy certificates can then be managed and configured separately, and won't be automatically generated on startup.
- For the clusters, we'll add additional credentials to be distributed along with the existing credentials.

If the proxies aren't being externally managed, securing internal communications is transparent to the user, and could even be on by default.