Improve secrets-unseale RBAC configuration to avoid cluster-wide read/write of secret objects

If I understand it correctly, the controller does not make any assumption that it can read secrets cluster-wide. The current installed cluster role 'secrets-unsealer' is written such that the controller is granted with such capability, which it does not appear to be needing.

I suggest the ClusterRole be refactored so it has a cluster-scoped portion and a namespace-scoped portion. The cluster-scoped portion would allow cluster-wide access to sealedsecrets, while the namespace portion would allow namespaced access to secrets and events. By default both ClusterRole can be ClusterRoleBind to the same service account so nothing should have changed; but a cluster admin would remove the second ClusterRoleBinding and make it RoleBinding in the namespace where sealed secrets is being used.

Happy to come up with a PR if this is the right thing to do.

Start by inspecting the installed `secrets-unsealer` ClusterRole and the controller's RBAC manifests, then compare the permissions needed for sealedsecrets, secrets, and events. Done means the default behavior is preserved while cluster administrators can replace the namespaced ClusterRoleBinding with a RoleBinding for a selected namespace.

Written by the indexing model from the issue text.