Data layout strings don't capture scalable vector alignment

LLVM does not require that a scalable vector's multiplicand is equal to a given fixed vector size in a target's data layout. Yet the alignment obviously must not *vary* based on the scalable vector's `vscale` multiplier, as that wouldn't be very... er... scalable. Yet, existing targets have surface-language types for scalable vectors which reflect layout constraints that aren't captured in LLVM's way of specifying data layout.

I am mostly thinking of AArch64 here: the predicate vector type, AKA `svbool_t`, apparently has an alignment of 2 (in bytes, so 16 bits)? That's fine by me, but I can't find that in the data layout strings for aarch64 targets.

I *could* assume that other scalable vectors on AArch64, as they are intended to use a multiplicand that is 16-byte-sized, use a 16-byte alignment. That's because [the LangRef says](https://llvm.org/docs/LangRef.html#data-layout) the default data layout, unless specified, is `"e-p:64:64:64-S0-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a:0:64"`. This would also conceivably cover RISCV vectors, as, except for masks, their multiplicand is apparently always supposed to be 8 (i.e. from `` to ``).

But that rule doesn't cover the scalable vector mask types they use.

This information can be *slightly* important for frontends concerned with generating compatible code with *other* frontends. While they can conceivably hand-reimplement whatever rule is in play, it's much better if they can just use what LLVM knows.

Possible solutions:
1. Specify `vscale`d vectors have the same alignment as the same vector without `vscale`, and add `-v16:16:16` to AArch64's data layouts (elegant, but conceivably something an ISA could disagree with).
2. Add an explicit alignment "field" to data layout strings for vscaled vectors and specify this for AArch64 and RISCV targets (most compatible, albeit with the most busywork).
3. Specify the alignment of the multiplicand must be exactly equal to size, essentially hardcoding the current values (likely to become incorrect, but hey, if it works).
4. Demand everyone hand-reimplement whatever architecture-specific rules are in play... and then actually specify the alignment rules for SVE and RVV.

Start with the LangRef data layout section and the AArch64 and RISCV target data layout strings. Compare how scalable vector and mask alignment is currently represented, then determine which proposed encoding is accepted. Done means the alignment rules are represented consistently for the affected targets and documented for frontend users.

Written by the indexing model from the issue text.