Make `github_app_installation_id` optional

What would you like added?

github_app_installation_id is currently required. This creates an overhead since k8s users who are allowed to create RunnerSet - most often are not allowed to create Secrets. Requiring github_app_installation_id also requires to create a separate secret per each organization.

Also, it doesn't seem like webhook-based scaling can be used at all right now in a multi-tenancy mode, unless one install apps and have multiple webhook deployments.

Why is this needed?

To allow users to self-register their runners in my cluster securely. To support webhook based scaling.

Additional context

https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app explains how to authenticate to GitHub "as app". The process is as simple as generating a local JWT and signing it with that same private key from github_app_private_key. The token has to be expiring within 15 minutes. Then you can list all installations of the app using a request like this:

curl --request GET \
--url "https://api.github.com/app/installations" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer YOUR_JWT" \
--header "X-GitHub-Api-Version: 2022-11-28"

In the response you can find github_app_installation_id mapping to the respective organizations by their slug. Therefore the github_app_id and the github_app_private_key is sufficient enough information, and that one secret can be reused across as many organizations as needed as long as app is installed on them.

Start with the controller's handling of github_app_installation_id and the GitHub App authentication flow; the issue provides the app-installations API request and the github_app_id and github_app_private_key inputs. Done means RunnerSet users need not create a separate organization Secret, while webhook scaling can resolve an installation by organization and explicit installation IDs remain supported.