`windows-gnu`: Adhere to MinGW convention for build outputs

[Doekin]

This PR potentially addresses issues #20039, #21103, and #16811.

Background

As outlined in #20039, when attempting to link a library named foo, the default search paths are foo.dll, foo.lib, and libfoo.a. However, the conventional DLL name format in MinGW is libfoo.dll and libfoo.dll.a. This mismatch can cause issues when working with build tools like CMake. This PR aims to resolve the inconsistency and improve compatibility.

Changes

• Updated fn fileExt(of: ObjectFormat, arch: Cpu.Arch) in std.Target.ObjectFormat to fn fileExt(of: ObjectFormat, abi: Abi, arch: Cpu.Arch).
• Changed default output names for MinGW targets:
  • Object files: .obj → .o
  • Static libraries: foo.lib → libfoo.a
  • Shared libraries: foo.dll → libfoo.dll, import libraries: foo.lib → libfoo.dll.a
  • Debug symbols: .pdb → DWARF format.
• Adjusted library search paths to reflect the new output names.
• Default behavior updated to not emit import libraries for executables or shared libraries when targeting the GNU ABI.
• Added support for the -mwindows linker flag (complements #11396).

Example

GCC/Clang generate a 66KiB file when creating a simple shared library. Previously, zig 0.13 would generate three files: a.exe (144.5 KiB), a.pdb (872.0 KiB), and foo.lib (1.2 KiB). After these changes, zig cc generates a single file: a.exe (874.0 KiB).

Additionally, when attempting to link to a non-existent library, the error message now reflects the updated search order:

Before

$ zig cc -target x86_64-windows-gnu main.c -lfoo -L.
error: unable to find dynamic system library 'foo' using strategy 'paths_first'. searched paths:
  .\foo.dll
  .\foo.lib
  .\libfoo.a

After

$ zig cc -target x86_64-windows-gnu main.c -lfoo -L.
error: unable to find dynamic system library 'foo' using strategy 'paths_first'. searched paths:
  .\libfoo.dll
  .\libfoo.dll.a
  .\foo.dll
  .\libfoo.a
  .\foo.lib

[alexrp]

Disabled default import library emission in zig cc mode (still enabled by default in zig build).

This is the only part of this PR for which the rationale is not immediately obvious to me. Can you elaborate on this point?

[Doekin]

Thank you for your feedback.

When using zig cc as a replacement for LLVM-MinGW, I noticed that main.lib was generated alongside HelloQt.exe. Since GCC and Clang do not emit import libraries by default, I felt it would be more consistent to align zig cc with this behavior.

[alexrp]

Ok, that makes sense. I would suggest including that rationale in the commit message.

[inschrift-spruch-raum]

How is the current progress?