Use of kubernetes.io/tls instead of Opaque for Certificates

Nobody has claimed this yet.

## Feature Request
Replace Certificate type to use kubernetes.io/tls for web-hooks and api-service implementation

### What problem are you trying to solve?
To make tls secret consistent with Kubernetes type(kubernetes.io/tls) that facilitates use of cert generators like cert-manager
### How should the problem be solved?
By using tls.key and tls.crt instead of key.pem and crt.pem
```
File: linkerd2/pkg/k8s/labels.go

// IdentityIssuerKeyName is the issuer's private key file.
IdentityIssuerKeyName = "key.pem"

// IdentityIssuerCrtName is the issuer's certificate file.
IdentityIssuerCrtName = "crt.pem"
```
### What do you want to happen? Add any considered drawbacks.
None

### Any alternatives you've considered?

Alternative is to mount tls.key and tls.crt as subpath that maps to key.pem and crt.pem. Though doable, it is cumbersome.

### How would users interact with this feature?

No direct user impact.

Start in linkerd2/pkg/k8s/labels.go, then search for uses of IdentityIssuerKeyName and IdentityIssuerCrtName in the webhook and API-service implementations. Update the certificate key names to the Kubernetes TLS names and verify that those consumers use tls.key and tls.crt consistently.

Written by the indexing model from the issue text.