Various Fixes and enhancements in x86 intrinsics

[sayantn]

• Updated the x86-intel.xml to be a more recent update of Intel Intrinsics Guide (v3.6.8)
• Added functionality to auto-generate a missing-x86.md for ease of implementation
• Updated disassembly to allow windows-gnu targets (they have the same implementation as linux targets, as that uses objdump from binutils, and binutils is a dependency of GCC). Add the x86_64-pc-windows-gnu target in CI
• Fixed some of the stream intrinsics.
• modified floating-point reduce-add and reduce-mul intrinsics to NOT use simd_reduce_add_unordered and simd_reduce_mul_unordered as Intel specifies a strict associativity. Follow GCC and hand-implement the associativity ourselves (_mm512_reduce_add_ps and friends are setting fast-math flags they should not set #1533)
• Fixed _load_mask32 etc in AVX512BW (they should have taken a __mmask32/__mmask64 pointer, but took u32/u64 pointer)
• As moves never modify any flags, add preserves_flags to the asm! blocks for moves
• Fix _mm_loadu_si64 (it had target-feature sse, but needs sse2), _mm256_extract_epi64, _mm256_extract_epi32, _mm256_cvtsi256_si32 (these had target-feature avx2, but need avx).
• Fixed _mm_cvtt intrinsics (they were actually calling vcvtss2si, when they should call vcvttss2si)
• Removed all MMX support from stdarch-verify, and made the target-feature verification stricter
• Implemented the missing intrinsics mentioned in Missing x86 vendor intrinsics (SSE2, SSE 4.1, AVX2) #1178 with feature-gate simd-x86-updates (Tracking Issue for Missing BMI1, AVX2, SSE2, SSE4.1, SSE4a and TBM intrinsics rust#126936)
• Fixed _mm512_kunpackb
• Modified the reduce-max and reduce-min intrinsics to preserve associativity specified by Intel and to use the comparison function they described (which is NOT maxnum from LLVM)
• Bumped the OS in CI Docker containers to Ubunto 24.04 (except for in armv7-unknown-linux-gnueabihf and x86_64-unknown-linux-gnu-emulated)

Modifying fma has been moved to #1597
Masked load/stores are on standby due to rust-lang/rust#126919

[rustbot]

r? @Amanieu

rustbot has assigned @Amanieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[RalfJung]

This (and all other AVX2 non-temporal operations) should get the same safety comment that the older non-temporal stores have. See e.g. here.

[Amanieu]

I checked and only non-temporal stores have special memory orderings on x86. x86 non-temporal loads work just like normal loads.

[sayantn]

@Amanieu told that that doesn't apply to streaming loads, only streaming stores.

[RalfJung]

Oh, I didn't realize non-temporal loads even are a thing. More nightmare waiting to happen, I guess...

[ruriww]

I checked and only non-temporal stores have special memory orderings on x86. x86 non-temporal loads work just like normal loads.

Is there a reason the non-temporal loads are written with inline assembly then? It generates extra instructions when offsetting. https://godbolt.org/z/os8bG3Efr