Windows can't handle symlinks in the repository very well, especially broken ones

While working on packaging Cabal 3.14 with GHC 9.12.1, I noticed that https://github.com/haskell/cabal/commit/4f01b764125dac783fca745baf5bffafb6883937 added a broken symlink to the repository.

This broke GHC's source distribution because we use `tar --dereference` to construct the source archive which instructs `tar` to "follow symlinks; archive and dump the files they point to."

However, when the directory to be archived contains a broken symlink, this results in:

```
/usr/bin/tar: ghc-9.13.20241009/libraries/Cabal/cabal-install/tests/fixtures/project-root/cabal.project.symlink.broken: File removed before we read it
```

I believe the reason we do this is because Windows itself doesn't have very usable or consistent handling of symlinks in archives.

For instance, extracting a zip archive (such as https://github.com/haskell/cabal/archive/refs/heads/master.zip) on windows using windows explorer results in symlink files being replaced by regular files whose content is the path to the target of the symlink.

On the other hand, extracting a tar archive with symlinks using the Mingw `tar` utility shipped with GHC itself, we get the contents of the symlink target "inlined" into the symlink itself, but this results in an error when the target of the symlink doesn't exist.

This can cause breakage in the testsuite depending on how you extract the files. For instance, if you extract a source zip of cabal using windows explorer, the contents of `cabal-testsuite/PackageTests/ReexportedModules/p-fail-other/Private.hs` would be the literal string `../p/Private.hs` which would cause tests to fail I imagine.

-------

I think we will just exclude this broken symlink from the source archive we distribute with GHC, so fixing this isn't time critical, but I imagine this problem might also create headaches for source distributions of Cabal itself.