Two reasons:

First, this allows us to test more of the algorithm, as the (slow)
reference implementation supports multiple associated data items, large
values for tau, ...

Second, this avoids the segfault crash, which is a limit of the fast
implementation (the assumption there is that data is aligned properly,
and even a read out-of-bounds will not cause a segfault).

I just want to ensure that we get the same encrypted values as the
reference (which seems fine), but for some reason, I get a lot of
crashes in aez:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==15467==ERROR: AddressSanitizer: SEGV on unknown address 0x7b34b0420000 (pc 0x6371fcd8f682 bp 0x7ffceb91abf0 sp 0x7ffceb91a950 T0)
==15467==The signal is caused by a READ memory access.
    #0 0x6371fcd8f682 in _mm_loadu_si128 /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/include/emmintrin.h:706:10
    #1 0x6371fcd8f682 in loadu /home/daniel/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/aez-0.0.7/aez5-impls/aesni/encrypt.c:107:46
    #2 0x6371fcd8f682 in cipher_aez_core /home/daniel/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/aez-0.0.7/aez5-impls/aesni/encrypt.c:572:32
    #3 0x6371fcd8d581 in aez::Aez::encrypt::h56048920113a17d9 /home/daniel/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/aez-0.0.7/src/lib.rs:118:13

The crash

It doesn't matter much because we barely expect tau > 16, but if
somebody decides to use aez as a way to generate a lot of pseudorandom
bytes, then oh well.

With this change, we make better use of SIMD block xor'ing if available.