Parameterized repository name

### What feature do you want to see added?

With `gitSCM` I can do:
```
gitSCM {
userRemoteConfigs {
userRemoteConfig {
credentialsId("github-token")
url('https://github.com/Owner/^${repo}.git')
name("origin")
refspec('+refs/pull/^${PR_NUMBER}/head:refs/remotes/origin/PR-^${PR_NUMBER}')
}
}
```
and dynamically load a repository based on the job parameters.

but trying similarly with `github` SCM:
```
github('Owner/^${repo}')
```
results in:
```
hudson.plugins.git.GitException: Command "git fetch --tags --force --progress --prune -- origin +refs/heads/PR-183:refs/remotes/origin/PR-183" returned status code 128:
stdout:
stderr: remote: Repository not found.
fatal: repository '[https://github.com/Owner/${repo}.git/](https://github.com/Owner/$%7Brepo%7D.git/)' not found
```

(The `^` is due to being Job DSL inside a Helm YAML file.)

The reason for the job parameter used in the repository name is this job acts as a special "hold open integration testing environment setup" mode that is triggered for any repository by a special URL put in a GitHub PR comment. So people can click the comment link and trigger this Jenkins job to do a stand-up of the integration environment and then hold it open (waiting for Jenkins input) until they click another link and push the Jenkins Job UI button to teardown the deployments.

### Upstream changes

_No response_

### Are you interested in contributing this feature?

_No response_

Start by tracing the GitHub SCM entry point that handles `github('Owner/${repo}')` and compare it with the parameterized `gitSCM` example in the issue. Determine how repository parameters should be resolved; done means a GitHub SCM checkout accepts the parameterized repository name without treating `${repo}` literally, with coverage for the requested behavior.

Written by the indexing model from the issue text.