Supporting reading TLS data from places other than Kubernetes Secrets

When deploying a webhook, it may be desirable to _not_ make use of the `certificates` controller (for generating a TLS certificate for the webhook), nor reading the TLS data _from_ a Kubernetes secret (e.g. in the case where some form of TLS certificate/identity document is already available within the webhook pod).

It is already possible to _not_ instantiate the certificate controller (by excluding it from the call to `sharedmain.WebhookMainWithConfig`, however the `webhook.Run` method explicitly sets the GetCertificate field on the `http.Server` to one that requires a Secret lister to function: https://github.com/knative/pkg/blob/b0c121fb667f02e7536b09790b2507842b7300dd/webhook/webhook.go#L187-L206

Ideally, this would be one of a number of optional mechanisms for loading TLS certificate data. This would increase the flexibility of the `knative.dev/pkg` package.

I'm considering whether we should simply allow setting `GetCertificate` directly, however changes are needed to `webhook.New` which currently fetches the SecretInformer from the SharedInformerFactory (thereby causing the informer factory to require read permission on secrets to start): https://github.com/knative/pkg/blob/b0c121fb667f02e7536b09790b2507842b7300dd/webhook/webhook.go#L110-L115

I think we could introduce a new `NewWithCertificateSource` or something, which would allow a user to override this behaviour (and the existing behaviour of the New function could be retained without breaking Go API compatibility).

/kind feature

Start in webhook/webhook.go, especially New and Run around the referenced SecretInformer and GetCertificate code. Trace how WebhookMainWithConfig constructs the webhook and determine how an alternate certificate source could avoid requiring Secrets access while preserving New's existing behavior. Done means webhook TLS data can be supplied without the certificates controller or a Kubernetes Secret, with the API compatibility considerations addressed.

Written by the indexing model from the issue text.