mingw: delete support for legacy mingw.org toolchain

[vszakats]

Drop support for "old" / "legacy" / "classic" / "v1" / "mingw32" MinGW:
https://en.wikipedia.org/wiki/MinGW, https://osdn.net/projects/mingw/
Its homepage used to be http://mingw.org/ [no HTTPS], and broken now.
It supported the x86 CPU only and used a old Windows API header and
implib set, often causing issues. It also misses most modern Windows
features, offering old versions of both binutils and gcc (no llvm/clang
support). It was last updated 2 years ago.

curl now relies on toolchains based on the mingw-w64 project:
https://www.mingw-w64.org/ https://sourceforge.net/projects/mingw-w64/
https://www.msys2.org/ https://github.com/msys2/msys2
https://github.com/mstorsjo/llvm-mingw
(Also available via Linux and macOS package managers.)

Closes #11625

[vszakats]

I may have missed some bits, feel free to update, or report.

Also, I'm uncertain if we announced this for 8.3.0 (released in September), or after 8.3.0. If the latter, feel free to flag it "next-feature-window".

[bagder]

The checks for __MINGW32__ that we have in the code, is that define set by any other versions than mingw v1? If so, we could remove all those.

The predef details seems to suggest that's only set by v1?

[bagder]

I think we have said we will remove this in September, so it misses the August feature window.

[vszakats]

__MINGW32__ should cover both old and new mingws, and mingw-w64 definitely keeps defining it. We also use __MINGW64_VERSION_MAJOR when we specifically look for mingw-w64, vs. the old one. Now that we don't have the old one, I think we are safe to fall back to __MINGW32__ for these cases.

Either way, good idea to check these. I'll review them.

[vszakats]

This KNOWN_BUG might need a re-evaluation: #3125

[jay]

note __MINGW64_VERSION_MAJOR is not a compiler predefine, it is defined by _mingw.h so if we have to evaluate it in the future then we'll need that include

[vszakats]

I'm aware. This patch deletes all uses of __MINGW64_VERSION_MAJOR. We can reinstate _mingw.h once we need to check for a specific mingw-w64 version. This is fairly rarely needed in my experience. We might also leave it there to mark its position and disable it with #if 0, but I'd avoid including headers we don't actually use.

[jay]

I just landed #10056 which has a legacy mingw workaround so when you rebase on master you'll want to remove these lines:
889c071#diff-ee813638cd7ec84110df50039b34c74fab8c79ef2b916858fdb6f19f5121a6abR63-R97

[vszakats]

Thanks @jay, it's done now.

[vszakats]

I deleted a list of compatibility constants, that were not marked "old mingw"-specific in the source.

Part of them had this information in the commit message of 3d3a3f9. With the rest I took a chance and assumed that if those constants were already defined by mingw-w64 1.0 (2011-09-26), they were also present in the official SDK released with supported MSVC versions (2010 and later).

curl also seems to support Pelles C. I have no idea about what's available there and CI doesn't test it. AFAIR Pelles C used to have fairly decent Windows headers. Tried to download it but even binaries are only offered via cleartext HTTP and even that was a 404. The compiler feels abandoned. We can restore any necessary compatibility macro as we go.

Also, there may be more compatibility macros that were added for old-mingw, but not marked as such.

We might also exclude such updates from this PR if this feels risky.