[aws-sigv4-proxy-admission-controller] Admission controller fails to recover if no pods are available to service requests

**Describe the bug**
A concise description of what the bug is.

By default the aws-sigv4-proxy-admission-controller mutating webhook is applied to all namespaces. This includes the namespace that the controller webhook deployment is running in. This creates an issue whereby if the controller webhook pods fail, it is not possible to start new pods, as there is nothing to service the webhook requests. This ultimately stops any further pods scheduling on a cluster.

**Steps to reproduce**
- Deploy aws-sigv4-proxy-admission-controller helm chart
- Delete all controller webhook pods created by deployment
- Observe that further pods do not come back up.

**Expected outcome**
A concise description of what you expected to happen.
Failure of all pods in the aws-sigv4-proxy-admission-controller deployment should not be unrecoverable. If this namespace is excluded, when the pods can be rescheduled, it will recover.

**Environment**

* Chart name: aws-sigv4-proxy-admission-controller
* Chart version: 0.1.2
* Kubernetes version: 1.27
* Using EKS (yes), if so version? 1.27

**Additional Context**:

Start with the aws-sigv4-proxy-admission-controller Helm chart and its mutating webhook configuration, focusing on how the controller's own namespace is selected. Reproduce the failure by deleting all controller webhook pods, then verify that excluding the controller namespace lets the deployment reschedule and recover without blocking new pods.

Written by the indexing model from the issue text.