Forbid disabling SSE on x86 targets that have SSE in their "baseline"

[RalfJung]

Passing -Ctarget-feature=-sse on an x86-64 target currently produces an ugly LLVM error.
Doing the same on a x86-32 target leads to unsound floating-point behavior.

Therefore, I think we should deprecate and eventually fully forbid toggling the sse/sse2 target features on x86 targets, except for those targets that do not have these features to begin with (e.g. i586-unknown-linux-gnu).

I am implementing some machinery here that could help with that, but properly implementing this will be tricky since one can also use -Ctarget-cpu to disable these target features.

Once this is implemented, we have some options for improving the Rust ABI on these targets as well:

• on x86-32, we could use SSE registers to return float values, instead of PassMode::Indirect
• on all x86 targets, we could pass SIMD vectors of up to 128 bits in registers rather than indirectly

Here, compiler team triage decided "Current Tier 1 x86 targets require SSE-based floats at minimum". The concrete proposal above got MCP'd in rust-lang/compiler-team#808.

Open questions

How do we best implement this? It's non trivial since -Ctarget-cpu can alter the sse/sse2 feature gates, so our usual approach of just checking which target features got toggled with -Ctarget-feature does not work.

To make things worse, the way we control whether sse/sse2 is available in the "basline" is via the base.cpu field, not via the explicit list of target features, so if we want to do things "only if the baseline has SSE", that's non-trivial to implement. Maybe we should just add a bool field to the target spec that directly controls "use SSE registers for Rust ABI" or "requires SSE registers" or so?

Cc @bjorn3 @workingjubilee @Amanieu

[RalfJung]

With #134794 there would be a fairly straight-forward way to implement this: add a way for a target to explicitly request a "hardfloat-with-sse" ABI (I am imagining a new rust_abi field in our target specs), and mark sse2 as required target feature for that ABI.

If we do that, setting -Ctarget-cpu to a non-SSE model will not change the ABI; instead, sse2 will silently be enabled anyway. That would be sound from an ABI perspective but likely quite surprising. So instead of forcibly enabling ABI-required features no matter what the target spec and -Ctarget-cpu say, we should probably check if ABI-required features are enabled and emit a warning (and eventually an error) otherwise.