Better test coverage for 256-bit and 512-bit vectors

[Shnatsel]

The newly added tests were generated by Claude Code with Opus 4.5 backend, since there's way too many of them to hand-write.

In the future we might want to add a more rigorous automatic generation of test cases for various vector sizes using an approach along the lines of fearless_simd_gen, but this is a simple first step towards increased test coverage.

I kept the newly added tests separate and the original handwritten tests intact to so that this extra code could be easily scrapped if it ever becomes a liability.

The 512-bit test file contains more tests than the 256-bit one because mod.rs already includes some handwritten tests for 256-bit vectors, so they don't have to be duplicated in the 256-bit tests file.

[Shnatsel]

Github Actions are down right now: https://www.githubstatus.com/incidents/xwn6hjps36ty

But the newly added tests pass for me locally on x86 and in WASM.

[LaurenzV]

I guess there is no harm in having them, but would like to hear the opinion of someone else, too.

[Shnatsel]

All the tests pass under Address Sanitizer added in #193 and on the emulator added in #197, which is encouraging. Those PRs aren't very useful without this one though, since the coverage for larger vector sizes is still very limited otherwise.

[raphlinus]

If the main question is whether we allow LLM generated code, then I think the answer is yes. The size is a bit daunting, but probably that's what it takes to test the functionality, as the surface area is large.

Skimming it, it seems reasonable – most of the tests just supply arguments to methods, then do assert_eq! on the answer. It's possible the sheer number of lines of code could be reduced by iterating over argument/result tuples, but on the other hand that would make control flow more complex.

So yes, I approve.