x86_64: implement win64 abi for more vector types #35865

Unblocks #35674 with:

--- a/test/tests.zig
+++ b/test/tests.zig
@@ -2019,35 +2019,35 @@ const c_abi_targets = blk: {
 },
 },
 
- //.{
- // .target = .{
- // .cpu_arch = .x86_64,
- // .os_tag = .windows,
- // .abi = .gnu,
- // },
- // .use_llvm = false,
- // .c_defines = &.{"ZIG_BACKEND_STAGE2_X86_64"},
- //},
- //.{
- // .target = .{
- // .cpu_arch = .x86_64,
- // .cpu_model = .{ .explicit = &std.Target.x86.cpu.x86_64_v2 },
- // .os_tag = .windows,
- // .abi = .gnu,
- // },
- // .use_llvm = false,
- // .c_defines = &.{"ZIG_BACKEND_STAGE2_X86_64"},
- //},
- //.{
- // .target = .{
- // .cpu_arch = .x86_64,
- // .cpu_model = .{ .explicit = &std.Target.x86.cpu.x86_64_v3 },
- // .os_tag = .windows,
- // .abi = .gnu,
- // },
- // .use_llvm = false,
- // .c_defines = &.{"ZIG_BACKEND_STAGE2_X86_64"},
- //},
+ .{
+ .target = .{
+ .cpu_arch = .x86_64,
+ .os_tag = .windows,
+ .abi = .gnu,
+ },
+ .use_llvm = false,
+ .c_defines = &.{"ZIG_BACKEND_STAGE2_X86_64"},
+ },
+ .{
+ .target = .{
+ .cpu_arch = .x86_64,
+ .cpu_model = .{ .explicit = &std.Target.x86.cpu.x86_64_v2 },
+ .os_tag = .windows,
+ .abi = .gnu,
+ },
+ .use_llvm = false,
+ .c_defines = &.{"ZIG_BACKEND_STAGE2_X86_64"},
+ },
+ .{
+ .target = .{
+ .cpu_arch = .x86_64,
+ .cpu_model = .{ .explicit = &std.Target.x86.cpu.x86_64_v3 },
+ .os_tag = .windows,
+ .abi = .gnu,
+ },
+ .use_llvm = false,
+ .c_defines = &.{"ZIG_BACKEND_STAGE2_X86_64"},
+ },
 .{
 .target = .{
 .cpu_arch = .x86_64,

• I finally hit a case where some generated code wanted to use an identifier that clashed with a zig.h identifier, so I banned all identifiers starting with zig_, but this broke the hack of defining extern zig declarations in zig.h which exists until inline asm specifies the target (e.g. .x86_64 vs .c), so in the interest of not holding up the dependent PR, I just read some gcc docs and updated the hack to match what the C compiler needed it to be.
• The new coverage depends on #35674 to pass, but that PR depends on this PR to pass, so I just commented out the tests to unblock the dependency loop (which I verified locally with both PRs applied, and any future breakage can be addressed in the other PR), with this PR being a bit too big to wait for the other PR to be reviewed before being merged.
• The other PR is failing when the x86-64 backend attempts to emit certain vector types over the C abi, so I tried to find the minimum set of vector types that had full coverage of all the insane things clang can do, and it's a lot, and then I added support to the x86-64 backend for these types in both the sysv and win64 calling conventions, which was not previously reasonable to do for win64 without test coverage that will become possible with the improved coff linker.
• I typed the tests using mostly rectangle editor commands for the repeating patterns in a sequence of numbers (all I really care about is that they are different within a test so that e.g. two parts of an argument aren't swapped between two registers which would pass if all the elements were the same or followed a trivially repeating pattern) for one element type, and then copy pasted it and replaced the element type with a different one. I try not to do much if any direct generation of tests with scripts because that makes it too easy to just have too many tests when the better solution would have been to pick a different testing strategy such as auto generation of types with a fuzzer that then generates some code with equivalent C and Zig definitions and produces a test corpus based on the code coverage of compiling that code with a self-hosted backend, but having input generation and code coverage in different processes is too advanced for the current fuzzer, or equivalently combining the test code and compiler into the same process, which I'm not sure how best to do. I think I did use a script to generate the bool vector test cases in previous PR, because it pretty difficult to generate a non-repeating sequence of bits (I did originally try manually using parity patterns which are, by definition, non repeating, but it's still too much to keep track of by hand). However, even then, I probably only used that for the literal contents of the vector literal, and then wrote the verification code by using editor commands to transform the literal to a sequence of asserts, and as usual the test itself catches any typos I might make.