Stop exposing "shift by vector" via operator overloading?

Nobody has claimed this yet.

The "shift left by vector" and "shift right by vector" operations don't lower to hardware operations on many platforms. On WebAssembly and SSE4.2, they all fall back to scalar operations. On AVX2, they're only vectorized for 32-bit and 64-bit operands.

It seems like a bit of a footgun to expose such operations in a way that looks identical to the much faster "shift by scalar". For example, [`clatter` uses a vectorized shift as part of an RNG](https://github.com/Ralith/clatter/blob/ea2f36ae7ddc32b7ed759d0dd1de2513b2575e52/src/hash.rs#L7), and [switching to a different algorithm that uses a non-vectorized shift is faster in practice](https://github.com/valadaptive/clatter/blob/30a7b47ebcba076a7c9e82221c128f2bb9532039/src/hash.rs#L5-L13).

It also makes it easier to accidentally use a vectorized shift when a scalar shift would do. You'd probably expect the two code snippets below to produce identical code:

```rust
let x: u32x4 = y >> 5;
```

```rust
let x: u32x4 = y >> u32x4::splat(simd, 5);
```

All the other operations take an `impl SimdInto` as the right-hand side and just call `splat` internally, so it's reasonable to assume that's what happens for the shifts as well. In this case, however, the latter snippet is slower.

No repository file or test is named; start by locating the shift operator implementations and the existing SimdInto right-hand-side handling. Compare scalar and vector shift behavior on WebAssembly, SSE4.2, and AVX2, then define the API change and verify that scalar-looking shifts no longer select vector shifts.

Written by the indexing model from the issue text.