Per the ARMv8 manual, the valid range of shifts for the vector SLI
operations is "0 to the element width in bits minus 1."  The existing
SIMDe implementation creates an invalid shift in the case of 0, as
the shifts are (element width - n) - so, for a 0-bit shift on a
64-bit value, the shift is 64.  This is undefined per the C spec, and
leads to compiler warnings on build.

This fix changes the sli_n shift operations to work properly for the
valid range of values, shifting ((element width - 1) - n), with a
modified constant value to generate the same results (7f... instead
of ff...).

While the existing tests all pass with the change, a number of the
tests have been modified (and have new constant values generated) to
properly exercise and demonstrate the "n == 0" shift case.  These
test vectors were generated on an ARMv9 system (Google Compute Engine
C4A system), and pass on x86 hardware as well.

Co-authored-by: Egor Ignatov <egori@altlinux.org>

Closes: https://github.com/simd-everywhere/simde/issues/1219

The vst1_*_x4 built-in functions in GCC 11 produce incorrect results,
as following exanple, this patch circumvents the issue by avoiding these
functions in GCC 11 and earlier versions.

float32x2x4_t val = {{
        {0.10f, 0.20f},
        {0.30f, 0.40f},
        {0.50f, 0.60f},
        {0.70f, 0.80f}
    }};
    float result[16];

    vst1_f32_x4(result, val);

get result = {0.100000 0.200000 0.500000 0.600000 0.000000 0.000000 0.000000 0.000000}
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>

Resolved a build failure on ARM64 with GCC 11 caused by excess
elements in a vector initializer. The issue stemmed from the
`__builtin_shuffle` function, where the number of elements in
the argument vector(s) and the mask vector must match.

For more details, refer to issue #1211.
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>