make __m64/__m128i/__m256i types

[gnzlbg]

This PR makes __m{64, 128i, 256i} types instead of aliases and allows us to change the repr of these types without breaking client code. It also means that the only things users can do with these types is convert from/into them from other types (no splat, no operators, no extract, replace, store, etc.).

It also changes two places where the __m/i_x_ types were previously used but the other types make more sense:

• The _mm_slli_si128,_mm_bslli_si128,_mm_bsrli_si128, _mm_srli_si128 intrinsics shift bytes (so it makes sense for them to take i8x16 as an argument).
• whether the result of _mm_cmpestrm works on bits, bytes, u16, ... depends on the mode argument, so returning a __m128i makes more sense than an u8x16 (also for consistency with the other string manipulation intrinsics which already do this).

This partially fixes #214 . The only part of that issue that remains open is whether we should rename these types to something else (e.g. i1x64,i1x128, i1x256), but there is no consensus about this yet and that should be done in a different PR anyways.

---

This PR also:

• documents intrinsics that do not correspond to any instruction or should not generate any instructions: when going through the code some intrinsics were missing the assert_instr macro and I did not know if that was on purpose or an oversight, so I had to check them all. We were already doing this for some intrinsics but should probably try to be more disciplined about it.
• remove unnecessary mem::uninitialized/mem::transmute, probably from the times where we did not have the intrinsics to create uninitialized vectors or from/into.

[gnzlbg]

rustfmt is broken-ish (rust-lang/rustfmt#2260 fix hasn't landed yet?) and the latest upstream changes introduce a lot of tiny differences all over the place so I think it would be better to reformat the library after this and #229 are merged to avoid any conflicts.

[BurntSushi]

Looks great to me! Thanks for doing this!