Simd{U,I}128 blocked on... LLVM maybe?

[workingjubilee]

Obstacles to an effective implementation of SimdU128 and SimdI128:

• Crash in LLVM using i128 saturating intrinsics on PowerPC #104: If we emit LLVMIR for math on 128-bit integers on PowerPC, it crashes.
• See this comment by @programmerjake and the relevant Godbolt: the codegen backends do not generate efficient results, even given wide vectors to use.
• It's not clear what their alignment should be on many targets, and therefore their ABI, and therefore their usage, making our FFI story even worse.

Accordingly, it was removed in 92d643b, preventing any soundness issues but leaving several questions open.

This technically is a primitive type according to Rust, so we could probably figure out a way to get vectorized arithmetic on them anyways, LLVM notwithstanding.

• Bitops can probably be managed via transmutation
• We can use a vector as a "bigint" for addition.
• We could yield them to FFI as fairly opaque bit-vector types, which is probably what we'd have to do anyway for most SIMD FFI, if memory serves.

But as-is, using them is a performance hazard, which is counterproductive to the purpose of this library. The standard library does not support AtomicU128 on many targets either, so we're not exactly taking a huge hit in portability here.