It's same check as `HAVE_SIGSETJMP`.

Comment suggested it is special, but it used the same method as all
the other symbol detections. It also suggested this was a secondary
detection attempt, but there was no first one.

Based on results found on AppVeyor CI with VS2008-VS2010-VS2022
and mingw-w64 6 to 9, origina mingw-w64 1.0 release and current
11.0 release.

```
        /usr/local/Cellar/mingw-w64/11.0.1/toolchain-x86_64/x86_64-w64-mingw32/include/winsock2.h:15:2: warning: #warning Please include winsock2.h before windows.h [-Wcpp]
           15 | #warning Please include winsock2.h before windows.h
              |  ^~~~~~~
```

This seems to actually cause the warnings, after fixing the header
include order to really include winsock2.h before windows.h:
```
        Building C object CMakeFiles/cmTC_0da7d.dir/HAVE_IDN2_H.c.obj
        /usr/local/bin/x86_64-w64-mingw32-gcc -D_WINSOCKAPI_="" -I/usr/local/include -W -Wall -pedantic -Wbad-function-cast -Wconversion -Winline -Wmissing-declarations -Wmissing-prototypes
        In file included from .../curl/bld-cmake-win/CMakeFiles/CMakeScratch/TryCompile-7IYZyM/HAVE_IDN2_H.c:2:
        /usr/local/Cellar/mingw-w64/11.0.1/toolchain-x86_64/x86_64-w64-mingw32/include/winsock2.h:15:2: warning: #warning Please include winsock2.h before windows.h [-Wcpp]
           15 | #warning Please include winsock2.h before windows.h
              |  ^~~~~~~
        Linking C executable cmTC_0da7d.exe
```

After both fixes, the test is warning-free:
```
        Building C object CMakeFiles/cmTC_a2548.dir/HAVE_IDN2_H.c.obj
        /usr/local/bin/x86_64-w64-mingw32-gcc  -I/usr/local/include -W -Wall -pedantic -Wbad-function-cast -Wconversion -Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-long-long -Wno-multichar -Wpointer-arith -Wshadow -Wsign-compare -Wundef -Wunused -Wwrite-strings -Wcast-align -Wdeclaration-after-statement -Wempty-body -Wendif-labels -Wfloat-equal -Wignored-qualifiers -Wno-format-nonliteral -Wno-sign-conversion -Wno-system-headers -Wstrict-prototypes -Wtype-limits -Wvla -Wmissing-parameter-type -Wold-style-declaration -Wstrict-aliasing=3 -Wno-pedantic-ms-format -Wformat=2 -Warray-bounds=2 -ftree-vrp -Wduplicated-cond -Wnull-dereference -fdelete-null-pointer-checks -Wshift-negative-value -Wshift-overflow=2 -Walloc-zero -Wduplicated-branches -Wformat-overflow=2 -Wformat-truncation=1 -Wrestrict -Warith-conversion -Wdouble-promotion -Wenum-conversion -Wunused-const-variable  -o CMakeFiles/cmTC_a2548.dir/HAVE_IDN2_H.c.obj -c .../curl/bld-cmake-win/CMakeFiles/CMakeScratch/TryCompile-7JKzOa/HAVE_IDN2_H.c
        Linking C executable cmTC_a2548.exe
```

This breaks from autotools. autotools will need to be adapted
to avoid the unnecessary header check in case the lib is missing.

The curl source bits that use idn2 require BOTH to be detected.

Not ruling out a terrible custom mis-configuration that may end up
with both WIN32 and UNIX set, but this was the only file we did
consider this scenario, so it seems fairly unlikely.

When building for Cygwin or MSYS2, WIN32 is NOT set and UNIX is set.

`CMAKE_VERSION` supported since CMake 2.6.3

No longer used after b04e624 curl#3166

Move it before including Windows headers.

`NOT UNIX` / `WIN32` / `HAVE_WINDOWS_H` / `HAVE_WIN*_H` are used
interchangeably in the source. In practice these all mean the same
thing and logic expects them to be in sync.

We should end up using `WIN32` only in CMake sources to check for
Windows. And `_WIN32` in C sources.

There is Windows C compiler supported that seems to miss Windows
socket header: `__SALFORDC__`. This C compiler seems to be long
gone. If still around, it must support Windows sockets out of the
box.

i.e. use windows.h directly, instead via `lib/setup-win32.h`.

This makes it work without requiring `HAVE_WINDOWS_H` defined.

…ngw-w64

The pre-cached values for CMake and the `config-win32.h` ones were
wrongly set as unsupported.

mingw-w64 supported these since its 1.0 release.

autotools got them right.

I did not catch these when doing cross-build-tool reproducibility tests
for Windows. Reason being that the `gettimeofday` branch is overridden
by a `WIN32` one, so it's not used regardless of these settings.

It means that this fix doesn't change the build results. Two new headers
_will_ be included though and the detection results are correctly setup
now.

This is present in mingw-w64 on native Windows by default,
otherwise it's only detected when manually adding pthread lib.

But, the result of this feature check is never used on Windows
by the source code, because the `WIN32` branches override it.
It'd also make curl phtread dependent if it did use it.

Always overridden by `WIN32` branches in curl source code.
Otherwise it needs pthread and a constant that is not present
in mingw-w64 anyway.

Possibly clang-cl might support this, which might show up as MSVC
in CMake. I'm not sure, so revert.

This reverts commit 761361f.