Emit HAVE__FSTAT/HAVE__FSTATI64 so fstat matches struct stat on Windows

[Sqhh99]

Description of proposed changes

ConfigureChecks.cmake checks for _fstat and _fstati64 on Windows, but gmt_config.h.in never writes HAVE__FSTAT or HAVE__FSTATI64 into the header. As a result, gmt_notposix.h maps stat to _stati64 (because HAVE__STATI64 is set) but leaves fstat unmapped. So in gmtlib_read_ps, struct stat buf becomes struct _stati64, while fstat() still expects the CRT's own struct stat, which has a different layout:

• GCC 14+ (MinGW-w64) treats this as an error (-Wincompatible-pointer-types), as reported in mingw64 compiling failure #8825.
• MSVC only warns, but fstat writes a struct of a different size than buf.

#8826 worked around this for 64-bit builds only, by calling _fstat64 under #ifdef _WIN64. 32-bit MinGW builds still fail, and 6.6.0 fails on both.

This PR adds the two missing #cmakedefine lines. fstat is then mapped to _fstati64, which pairs with _stati64 on every Windows target. That makes the _WIN64 special case unnecessary, so it is removed.

How it was tested

I used MinGW-w64 GCC 13 with -Werror=incompatible-pointer-types, which behaves like GCC 14:

• A CMake configure under MinGW detects all four of HAVE__STAT, HAVE__STATI64, HAVE__FSTAT and HAVE__FSTATI64. The 6.7.0 Windows installer's gmt_config.h (an MSVC build) also defines HAVE__STAT and HAVE__STATI64.

• I compiled src/gmt_plot.c against the generated headers:

  	x86_64	i686
  master	compiles (because of the _WIN64 workaround)	error: passing argument 2 of 'fstat' from incompatible pointer type; expected 'struct stat *' but argument is of type 'struct _stati64 *'
  this PR	compiles	compiles

  With this PR the object files import matching stat/fstat pairs: _stat64/_fstat64 on x64 and _stati64/_fstati64 on i686.

• gmtlib_read_ps is the only fstat caller. The checks only run inside if (WIN32), so non-Windows builds are unchanged.

Follow-up to #8825 / #8826.

The fix and its analysis were developed with help from Claude (AI assistant). I checked the analysis myself, and the MinGW x64/i686 build results above are from real compiles.

Reminders

• Make sure that your code follows our style. Use the other functions/files as a basis.
• Add tests N/A: this is a MinGW/GCC 14 compile-time error that the test suite can't catch. GMT's Windows CI builds with MSVC only, and a MinGW CI job would be the real safeguard; I'm happy to propose one separately.
• Describe changes to function behavior N/A: no function's behavior or arguments change.
• Add documentation N/A: no new functionality.

[joa-quim]

Thanks. Let me find some time to tests this under a MSVC build.

[joa-quim]

Ok, tested and run the tests locally (MSVC build) run OK.