Add an option to resolve a `${JENKINS_GIT_REFERENCE_REPO_DIR}` environment variable

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

While working on #644 and the Jenkins-Dynamatrix project across a fleet of nodes doing Git, I came up with the idea that currently a job configuration (e.g. in an Organization Folder which generates Multi-Branch Pipeline folders and ultimately leaf jobs) is the one place to specify the git reference repository location. PR #644 addresses that such a location can become parameterized, to serve in fact multiple (bare) git index caches hosted under the specified location, however the location itself is assumed to exist at the specified path on all nodes doing `checkout` operations.

To avoid creeping the scope of that long-awaiting PR even further, I post the new idea separately. It is simple: allow the controller and build agents or even individual jobs to define an environment variable (tentatively namespaced like `JENKINS_GIT_REFERENCE_REPO_DIR`) and teach the git-client-plugin to resolve it (or throw an exception if present in the refrepo location string and not set in current node's `env`).

Also consider honouring such envvar if no (empty/null) location was passed by the job configuration, and perhaps not by `checkout scm` or `$class: GitSCM` settings - but then for these we should somehow support the case of "explicitly set to empty/null means to not use it". This would allow (persistent) build agents to use their caches without a special effort on job authors' side.

### Upstream changes

Loosely related to #644, may touch on nearby lines when parsing the refrepo location string. Maybe this issue is better addressed after that PR gets merged.

### Are you interested in contributing this feature?

Yes, but it seems to be a low-hanging fruit anyone can reap.

Start in the git-client-plugin code that parses the refrepo location string and trace how checkout operations receive it, comparing the nearby changes in PR #644. Review how the current node’s environment is available to controller, agents, and jobs, and clarify precedence for an unset variable versus an explicitly empty or null location. Done means the supported environment variable is resolved consistently, missing variables fail as specified, and the behavior is covered by tests.

Written by the indexing model from the issue text.