Can't find source when multiple dots are in main-is

[ag-eitilt]

This is issue 3 of 3 following up on potential cross-platform compatibility problems that were identified in #7429 (alongside #7479 and haskell/filepath#85). That PR fixed a bug in the path validation state machine, but in doing so I realized that some of the Windows idiosyncrasies weren't being checked; the resulting discussion revealed that most of them were supposed to be checked elsewhere, but I volunteered to verify that anyway, once I got time. I've since done so, and am now recording my results:

In testing final dots I happened to stumble across (another) weird issue with filepath recognition, this time involving files with more than one dot while building despite at least some other functions (namely cabal sdist) being perfectly happy with them. The error messages aren't particularly helpful, though they do hint at what might be going on; all are used as the payload of main-is, and complain on both FreeBSD and on a Windows VM:

• test..hs

  cabal: can't find source for test in .

• .test.hs

  cabal: can't find source for in .

• test.ext.hs

  cabal: can't find source for test in .

• ....hs

  cabal: can't find source for in .

There doesn't seem to be any problems including files of the same pattern in data-files, though I haven't yet tested c-sources and similar, as removing the leading dot on the main file in my test package. Seeing as main-is explicitly requires a .hs, .lhs or C-relative file, disallowing any or all of these could certainly be a reasonable solution. If we take that path, however, we should both make the error message more explicit (as that of passing a file with the wrong extension) and make cabal check -- and maybe others -- complain as well.

Do we want to allow any of these? The first seems relatively harmless, the second and third might be (situationally) helpful, and while the last is likely to just cause confusion, I'm not sure we want to regulate people's file naming habits.

[Mikolaj]

test.ext.hs is certainly completely legit. I can't imagine rejecting such a name.

[ag-eitilt]

Since platform:* tags have been added, I should clarify that I'm certain this is an issue on Linux as well (and Mac for that matter); the version of cabal-install I have access to on Gentoo is just slightly older than the 3.4 the test package uses, so I couldn't verify things in the brief time I booted up that OS. I don't see any reason why it would only affect these two OSs.