Can we provide an option to specify an existing self-hosted runner?

### Description

Rather than only relying only on ALZ provided Azure Container Instances as self-hosted runners, I believe a large majority of cloud engineers and architects may want to leverage their existing GitHub Enterprise [Server, Cloud, or EMU] self-hosted runners that are configured internally as a shared runner at the enterprise or organization level instead.

### Describe the solution you'd like

So, to accommodate these scenarios, can we offer an option as a parameter for the Deploy-Accelerator cmdlet to specify the [preferred] name or label of an existing Enterprise or Organizational level self-hosted runner or runner group that these engineers / architects would prefer to use. This way they can implement a simpler and less costly option while utilizing their existing investment in their own self-hosted runner(s).

### Describe any alternatives you've considered

For private or internal repositories for GitHub Enterprise members, the alternative is to set the "use_self_hosted_agents:" parameter to "false", but in such cases, the self-hosted runners would then have to be specified in the GitHub Enterprise workflow post ALZ bootstrap, which requires an extra and manual step.

### Additional context

Start by inspecting the Deploy-Accelerator cmdlet and the existing use_self_hosted_agents parameter. Trace how the bootstrap workflow selects Azure Container Instances as runners and how enterprise, organizational, or runner-group names could be passed through. Done means an option exists to select an existing self-hosted runner or group without the manual post-bootstrap workflow change.

Written by the indexing model from the issue text.