Enabling the `statusUpdateHook` should not always update the `manager_role` to allow creating service accounts, roles, and rolebindings.

What would you like added?

Currently, when we set runner.statusUpdateHook.enabled: true this makes two changes to the helm chart

1. It adds "--runner-status-update-hook" as a CLI param to deployment.yaml (https://github.com/actions/actions-runner-controller/blob/1a8abb6d3950d3a78715505312d88b201e6d8a49/charts/actions-runner-controller/templates/deployment.yaml#L67-L69)
2. It updates the manager_role.yaml to allow for creating service accounts, roles, and role bindings (https://github.com/actions/actions-runner-controller/blob/1a8abb6d3950d3a78715505312d88b201e6d8a49/charts/actions-runner-controller/templates/manager_role.yaml#L253-L278)

We would like the option to toggle on 1) without toggling on 2)

I suggest adding a new option, perhaps around (here: https://github.com/actions/actions-runner-controller/blob/1a8abb6d3950d3a78715505312d88b201e6d8a49/charts/actions-runner-controller/values.yaml#L65-L67):

runner:
  statusUpdateHook:
    enabled: false
    allowManagerRoleCreateServiceAccount: true # this is the new value

We will default it to true for backwards compatibility. If it is set to false though, 2) above will not apply.

Why is this needed?

We have set up our runners to use a custom service account already. This means that our runner-controller does not create the service account for the runners (see logic here: https://github.com/actions/actions-runner-controller/blob/1a8abb6d3950d3a78715505312d88b201e6d8a49/controllers/actions.summerwind.net/runner_controller.go#L304-L305).

Therefore, the permission we are forced to grant in 2) above goes unused. In the principal of least privelege, we don't want to permit this.

If we agree on naming of the config and the approach, I'm happy to make the PR for the change.

Start with charts/actions-runner-controller/values.yaml and the referenced deployment.yaml and manager_role.yaml templates to trace how runner.statusUpdateHook.enabled controls both changes. Render the chart with the proposed option set to false and verify that the status-update-hook argument remains while the service-account, role, and rolebinding creation permissions are not added; confirm the default preserves current behavior.