Select GNU tar for caching if available on hosted runners

Describe the bug

BSD tar has been problematic for the caching action for several reasons:

1. bsdtar does not handle recursive directory structures created by junction points - https://github.com/actions/cache/issues/315

2. bsdtar does not work with zstd compression, causing the process to hang - https://github.com/actions/cache/issues/301

3. Changing the PATH will cause the cache to switch between BSD tar and GNU tar causing compatibility issues on Windows (due to the zstd compression bug) - https://github.com/actions/cache/issues/465

4. BSD tar on MacOS corrupting executables and.dylib files - https://github.com/actions/cache/issues/460 and https://github.com/actions/cache/issues/403

On hosted runners, tar.exe is available in several locations locations:

1. BSD tar - C:\Windows\System32\tar.exe (Windows 2019 only)
2. GNU tar - C:\Program Files\Git\usr\bin\tar.exe
3. GNU tar - C:\msys64\usr\bin\tar.exe

Caching correctly selects GNU tar on Windows 2016 runners, since (2) shows up on the PATH. Windows 2019 runners use BSD tar because (1) shows up first on the PATH. (3) does not appear on the system PATH so it is never selected.

Given the problems with bsdtar, it seems we should either ensure GNU tar appears first on the system PATH or improve the lookup logic in the caching module to find GNU tar. Right now, a workaround is to explicitly set the system PATH:

    - name: Use GNU Tar from Msys
      if: ${{ runner.os == 'Windows' }}
      run: |
        echo "::add-path::C:\msys64\usr\bin"

Expected behavior
GNU tar is selected if it is available.

Desktop (please complete the following information):

• OS: Windows

Start by tracing the caching module's tar lookup and how Windows runners resolve tar.exe. Verify the behavior against the listed GNU tar locations and existing Windows cache behavior; done means GNU tar is selected whenever it is available without relying on a PATH workaround.