Add SSE2 backend

[Shnatsel]

Fulfills #256

SSE2 is guaranteed to be present in the baseline on x86_64, and the Rust i686 targets also guarantee its presence. You need to use the tier-2 i586 target to opt out. So this replaces Fallback on x86 and does not bloat the binary, even on 32-bit targets.

Not having SSE4.2 is quite rare these days, but this is still useful in contexts where dynamic dispatch is expensive. For example, this unlocks access to explicit SIMD in the png crate which uses SSE2 with autovectorization without runtime dispatch, but autovectorization sometimes regresses on newer rustc versions, so explicit SIMD is desirable.

To reduce the maintenance burden, most operations on SSE2 level reuse either the SSE4.2 path or the scalar fallback. Only a few select operations get dedicated SSE2 paths. I feel those exceptions are justified because autovectorization is still quite fickle. For example, individual calls to min() and max() autovectorize into identical assembly, but without intrinsics this falls apart and turns from 8 instructions into 181 - I've even experimented with alternative formulations of the fallback level to no avail:

#[inline(always)]
fn minmax_u8<S: Simd>(
    simd: S,
    a: &[u8; 16],
    b: &[u8; 16],
    min_out: &mut [u8; 16],
    max_out: &mut [u8; 16],
) {
    let a = u8x16::from_slice(simd, a);
    let b = u8x16::from_slice(simd, b);
    a.min(b).store_slice(min_out);
    a.max(b).store_slice(max_out);
}

[Shnatsel]

I went back and forth on this a bunch, but eventually decided to add fxsr checks everywhere since it's part of the baseline for x86_64 and i686 targets, and there are some uses for those instructions inside kernel! functions.

The tier3 target is probably just misconfigured, so now we disable SIMD on it instead of making potentially unsound calls.

[LaurenzV]

Once again mostly relying on our existing tests for correctness, but LGTM overall!

[LaurenzV]

I feel like at some point we should introduce constants for the names... But also not for this PR.

[Shnatsel]

The remarks are addressed, merging. I appreciate the in-depth review as always!