Draft: Add FF_GIT_CONFIG_LOCAL_ONLY to isolate from global/system git config

What does this MR do?

Add FF_GIT_CONFIG_LOCAL_ONLY to isolate from global/system git config

When enabled, define GIT_CONFIG_NOSYSTEM and point GIT_CONFIG_GLOBAL at the build's externalized git config file. This ensures credential helpers, insteadOf rules, and other settings from the runner user's ~/.gitconfig or /etc/gitconfig cannot leak into the build.

• Verify that a build-script git submodule update authenticates correctly when GIT_SUBMODULE_STRATEGY=none, relying on GIT_CONFIG_GLOBAL to expose the externalized config.
• Switch listGitConfig to git config --list --show-origin --show-scope so the validators can assert that, under FF_GIT_CONFIG_LOCAL_ONLY=true, the ext.conf is loaded at global scope and no system-scope config is visible (and vice-versa when the flag is off).
• Introduce anyLineMatches / noLineMatches helpers that regex-match the git config --list --show-origin --show-scope output. A scope- and file-pinned prefix asserts a setting is present at exactly that scope and file; or that it's absent anywhere using '.*'
• Factor the shared prefix fragments into named constants (gitConfigGlobalExtFile, gitConfigSystem, fromExtConf, fromGitConfig, remoteOriginWithToken, insteadOfWithMasked) to keep the four validators readable.
• Skip the pre_get_source hook when gitConfigLocalOnly is true, since that path has no shared cached-cred-helper to seed.
• Strip any GIT_CONFIG_* env vars so the caller's environment can't influence the test.
• Run the gitConfigLocalOnly=true cases in parallel regardless of the gitUrlsWithoutTokens value (the isolation makes it safe).
• Reduce git verbosity: GIT_CURL_VERBOSE and GIT_TRANSFER_TRACE are not useful for debugging and are not asserted.

Why was this MR needed?

• Depends on !6609:
  • this MR will be rebased on main after !6609 is merged
  • if this dependency MR is not yet merged, review the changes of this MR by looking at its specific commit.

What's the best way to test this MR?

What are the relevant issue numbers?

#39171