Signatures of all x86 intrinsics should match the spec

[gnzlbg]

In #251 it was discussed that we should make all x86 intrinsics match the spec.

That is, instead of being strongly typed (e.g. i32x4) they would match the spec and be loosely typed (e.g. __m128i).

There was general agreement on this by all the parties involved, but the discussion is still open. There are many reasons that led us here. What follows is just a summary of what I recall:

• We tried to make the intrinsics strongly typed and we did arguably succeed. Having a strongly typed SIMD library is doable in Rust. In the cases that we failed, it was because either the intrinsics were loosely typed by design, or due to implementation issues that we want to solve anyways (e.g. __m64 maps to x86_mmx but i8x8 does not).

• Strongly typing the intrinsics makes stabilization really really hard. We can't verify our implementation against the spec (which @alexcrichton has started to automate), the RFC must argue why each intrinsic has a particular signature in a 1:1 case basis, etc. There are 1000s of intrinsics, and we lack the manpower to write such an RFC, and probably achieve consensus on it. Stabilizing the loosely-typed intrinsics is much easier because we are just stabilizing the vendor spec, as is. No per-intrinsics rationale required.

• A strongly-typed wrapper can be provided in a third-party stable crate once the loosely-typed intrinsics are stabilized. @AdamNiederer 's faster crate is one example, but we can also imagine something lower-level like the current strongly-typed SIMD crate (e.g. @AdamNiederer has offered to kickstart such a crate).

Our primary objective is to allow writing good SIMD code in stable Rust. Loosely-typed intrinsics in the standard library are a step towards that goal that does not prevent adding strongly-typed intrinsics in the future.

Note 0: For now, the stdsimd crate will continue to provide strongly-typed vector types (e.g. f32x4). These types require unstable features that we don't plan to stabilize, and are part of the spec of other architectures (e.g. ARM), so they need to be provided by this library anyways.

Note 1: This means that we can stabilize the loosely-typed x86 intrinsics without stabilizing the strongly-typed vectors, which means that we can continue to evolve the strongly-typed vector types.

Note 2: This opens the door for some improvements to the strongly-typed vector types, like adding #185 (boolean vectors). One major argument against them was having to update the x86 intrinsics to use them properly. This wouldn't be the case anymore.