Prefer avx512vl_256 over avxvnni for 256-bit sized batches (#1381)

When both AVX-VNNI and AVX512VL are available, make_sized_batch/sized_batch
walks all_x86_architectures in order and picks the first arch matching the
requested lane count. For 256-bit float/double batches this selected avxvnni,
whose masked load/store lower to vmaskmov{ps,pd} — a ~3-uop op on Intel that
also does not store-forward. avx512vl_256 (which inherits fma3<avx2>, so every
non-masked op is byte-identical) instead lowers masked load/store to EVEX
k-register moves (vmovups{k}, _mm256_mask*), 1 uop and forwardable.

Reordering avx512vl_256 ahead of avxvnni makes 256-bit sized batches select it
whenever AVX512VL is present. VNNI-only targets (e.g. Alder Lake client) still
resolve to avxvnni, since avx512vl_256 is filtered out of supported_architectures
there — so no target loses codegen, and AVX-512 targets gain clean k-masking.

Note: avx512vl_256 uses EVEX-encoded 256-bit ops, which do not trigger the
512-bit license-based downclock on Skylake-SP/Ice Lake/Sapphire Rapids.

Author: DiamonDinoia

include/xsimd/config/xsimd_arch.hpp

@@ -163,7 +163,7 @@ namespace xsimd
 
     using all_x86_architectures = arch_list<
         avx512vnni<avx512vbmi2>, avx512vbmi2, avx512vbmi, avx512ifma, avx512pf, avx512vnni<avx512bw>, avx512bw, avx512er, avx512dq, avx512vl, avx512cd, avx512f,
-        avxvnni, avx512vl_256, fma3<avx2>, avx2, fma3<avx>, avx, avx512vl_128, avx2_128, avx_128, fma4, fma3<sse4_2>,
+        avx512vl_256, avxvnni, fma3<avx2>, avx2, fma3<avx>, avx, avx512vl_128, avx2_128, avx_128, fma4, fma3<sse4_2>,
         sse4_2, sse4_1, /*sse4a,*/ ssse3, sse3, sse2>;
 
     using all_sve_architectures = arch_list<detail::sve<512>, detail::sve<256>, detail::sve<128>>;