Fix undefined behaviour in keccak4x

[jschanck]

There are two uint64_t arrays declared in KeccakP-1600-times4-SIMD256.c that are accessed using _mm256_load_si256 but are not guaranteed to have 32 byte alignment.

#define CONST256(a) _mm256_load_si256((const V256 *) &(a))
[...]
#define ROL64in256_8(d, a) d = _mm256_shuffle_epi8(a, CONST256(rho8))
#define ROL64in256_56(d, a) d = _mm256_shuffle_epi8(a, CONST256(rho56))
static const UINT64 rho8[4] = {0x0605040302010007, 0x0E0D0C0B0A09080F, 0x1615141312111017, 0x1E1D1C1B1A19181F};
static const UINT64 rho56[4] = {0x0007060504030201, 0x080F0E0D0C0B0A09, 0x1017161514131211, 0x181F1E1D1C1B1A19};

This is (likely) the undefined behaviour detected by UBSan in #791.

The first commit of this PR fixes the alignment with a union type. The second commit backports some minor changes to the definitions of other macros in KeccakP-1600-times4-SIMD256.c from XKCP. Only the first commit is related to the undefined behaviour.

The UB issue is also present in XKCP, PQClean, and in our src/kem/kyber/pqcrystals-kyber_common_avx2. However it only manifests when the rho arrays are misaligned at compile time.

With the compilers I've tested, the arrays are correctly aligned when KeccakP-1600-times4-SIMD256.c is its own compilation unit. That's why, as Basil mentioned in the comments of #791, UBSan does not flag the new Kyber code.

We just happened to get unlucky with the layout of data sections when we included KeccakP-1600-times4-SIMD256.c into src/common/sha3/sha3x4_avx2.c. The situation could reverse with a compiler update, etc, so we should leave #791 open until it's fixed in Kyber or we switch Kyber over to common keccak4x.