Consider placing restrictions on paths for portability

[quasicomputational]

Spin-off from #5289. Windows has a number of characters that can't appear in path components. For portability, we should consider restricting the use of those in package descriptions. I started work on this but it's a yak shave of a yak shave and I realised it was a bigger task than I wanted to take on, with a few squidgy considerations, so here are my notes. I'm not a Windows person, so take all of this with a grain of salt.

• Backslashes could be forbidden in relative paths, since slashes are accepted as a path separator. Except we strictly need them for UNC paths.
• ? is needed for UNC paths.
• For absolute paths, you definitely do want to allow : and possibly UNC paths, too?
• I don't know if we need UNC for relative paths or not.
• I don't know what the other magic characters are forbidden for, or whether we can safely exclude them or if Windows users will complain about having some necessary syntax incidentally disabled.
• What about conditional sections? If you gate some weird pathnames behind os(linux), is that okay?
• The magic CP/M names (COM, NUL, etc) shouldn't be a problem if all file access goes through modern mechanisms, right? I'm not confident that it does, but we might view those call-sites as buggy and needing to be fixed rather than a reason to try to exclude the magical names.
• Case (in)sensitivity.

There are portability worries going in the other direction, too: POSIX paths aren't Unicode, but Windows paths are. Restricting to printable ASCII is one option, but that's horrible. Demanding UTF-8 is attractive, but that might be too controversial still?

Not all of these are necessary to get something useful done, but they're things to think about.

[hvr]

As I commented already in #5289; this makes sense for cabal check; but it certainly shouldn't keep me from using such non-portable paths in my .cabal description if I don't distribute via Hackage!

[quasicomputational]

One more consideration: globs can pull in non-portable pathnames, so even if the package description is perfectly portable, the package may not be. So cabal check or whatever will have to walk the tree.

[quasicomputational]

Some issues that have cropped up related to non-portable paths:

• On OS X, warn about filenames that only differ in case #783
• cabal sdist corrupted when using Unicode #2558
• Lack of support for non-ASCII characters in cabal sdist #3758
• Filename case on macOS #4739

[23Skidoo]

Yes, makes sense. Should be fairly easy to implement by adding a new check.