Updated stat sys function call support on Windows

[JackCarterSmith]

Following #256.

Why?

I propose a quick patch to directly use crt function _stat() on Windows platform instead of the interface provided by MinGW to avoid breaking compatibility with change in MinGW versions.
As stat() function signature didn't change, it's only a rework of the abstract interface of MinGW who cause a compatibility issue (and not a change in the CRT).

Regression testing

I've tested the changes in this PR using make check on a Ubuntu 22.04 platform with GCC-14 for native linux and with GCC-14 MinGW-w64 13 in cross-compilation.
Plus I tested on a test program directly on Windows using GCC-14 MinGW-w64 12 natively.

What does this patch involve?

This patch only change the stat() and struct stat redirection from MinGW to direct CRT (similar to how libcurl does it) only on Windows build. The linux sys/stat() is keep untouched.
The stat() symbol in the otutput .a lib on linux is still stat.
On Windows, the previous glitch generated a stat64 symbol, which aren't pushed in the tagged v13 of MinGW.
Now, with this patch, the symbol is _imp__stat64 instead and use the Windows UCRT .dll directly.

[rockdaboot]

LGTM

Would like to get a second opinion from @eli-schwartz

[JackCarterSmith]

Since it's been a while, I "up" this PR.

[JackCarterSmith]

Sorry to bother you @eli-schwartz, maybe I should have ping-ed the relevant person :)

[eli-schwartz]

Sorry, it's been a bit busy here recently so a direct ping is definitely a more reliable way to attract my attention. :D

I'm not a windows expert but this seems like a plausible way to use the underscore variant on mingw (which is what you want).

I might reword the commit message, mainly because I'm a kind of nitpicky person about commit messages.

avoid mingw stat wrapper on Windows

stat() is a mingw posix wrapper for the native Windows _stat() and friends. Although tempting to use for simplicity, the wrapper incurs overhead, such as making distribution of static libraries challenging (as the mingw version has to match exactly). Additionally some mingw releases are buggy and generate symbol linkage to missing symbols. Avoid the middleman and utilize the windows API directly.

[eli-schwartz]

And a general commentary on "update XYZ support" -- a commit message one-line summary should ideally be optimized to tell the reader as concisely as possible, what the intended outcome is. "Update XYZ" is not the goal, it's incidental to the goal of "avoid a potentially unreliable wrapper". Another possible description might be "make mingw static linking more robust".

[JackCarterSmith]

I don't mean to rush you! I sometimes forget things and lose track of time either :D

No problem with that—I completely agree with the principle and the content. I force-pushed the reword just as it is.

Thank you for the review and the commit tip!

[lhmouse]

mingw-w64 provides stat() with some overhead to work around bugs in _stat() in old MSVCR* DLLs, for example the latter may flag directories and device files as regular, and do not accept UNC paths which start with \\?\.

If you always link against UCRT you may ignore differences between stat() and _stat(), since both reference the same function. (and stat64() and _stat64(), and others likewise.)