Fix handling of relative builds dir

Summary

Fixes a bug where relative builds_dir configurations caused incorrect Git config paths to be constructed, preventing proper repository setup.

Problem

When builds_dir is configured with a relative path, setupExistingRepoConfig() was incorrectly constructing the path to .git/config by joining projectDir (which could be relative) with the git config file path. After the script changes directory into projectDir, this resulted in an invalid path like builds\\...\\PROJECT\\.git\\config instead of just .git\\config.

Solution

This MR fixes the issue by:

• Removing the projectDir parameter from setupExistingRepoConfig() since we're already in that directory after cd
• Using a relative path to .git/config since the working directory is already projectDir
• Leveraging the GLR_EXT_GIT_CONFIG_PATH environment variable (set by setupTemplateDir()) to get the absolute path to the external config
• Using CommandArgExpand with git config --replace-all to properly handle the include.path configuration
• Enabling the previously disabled "relative" test case in TestGitIncludePaths to ensure this scenario is covered

Additional Changes

• Simplified fromSlash() in PowerShell writer to consistently use filepath.FromSlash() for both pwsh and Windows PowerShell
• Updated submodule credential configuration to use --replace-all flag and proper quoting for paths with spaces
• Updated all related tests to reflect the new function signature and behavior

What's the best way to test this MR?

Use a shell runner with and without builds_dir = "builds dir" (with spaces) on Windows and Linux to verify:

• Repository cloning works correctly
• Git config includes are properly set up
• Submodules authenticate correctly

What are the relevant issue numbers?

Relates to #39150 (closed)