Arm implementations are currently disables since it is causing problems
on Drone.io, though I can't reproduce with qemu.  I'll need to try to
get it running on hardware.

This caused the header to be useless for detecting versions of clang
prior to 4.0.

I also changed a couple of the warnings we use to detect the version;
AFAICT the old ones would have worked, but these seem a bit more
likely to work everywhere.

This could be good for compilers which don't support
__builtin_shufflevector or __builtin_shuffle (like MSVC).

Everything involving pd or si128 needs at least SSE2

Fixes #696

I can't find any details on when this was fixed.

Without this we end up with messages like this for each function.

  /tmp/cc2WM2zv.s: Assembler messages:
  /tmp/cc2WM2zv.s:47871: Error: operand mismatch -- `rev16 v0.4h,v1.4h'
  /tmp/cc2WM2zv.s:47871: Info:    did you mean this?
  /tmp/cc2WM2zv.s:47871: Info:          rev16 v0.8b, v1.8b
  /tmp/cc2WM2zv.s:47871: Info:    other valid variant(s):
  /tmp/cc2WM2zv.s:47871: Info:          rev16 v0.16b, v1.16b

The second parameter was signed, but should have been unsigned.

Relevant GCC commit: 66da5b53107962a1c115a9686f2220de27f276f7

Fixes #695

This also adds a bunch of related native aliases which were missing.

There are no tests for this because it's not something we can feasibly
emulate on platforms which don't support it, and few platforms support
it.

It *may* be possible to implement this on AArch64.  It is controlled
by the FPCR register, but ACLE documentation says to access the FPCR
register using fegetenv/fesetenv, and AFAICT glibc doesn't expose a
way to access the relevant bits.  I think you can get at it via the
fpsimd_context struct in sigcontext.h, but portability is likely to
be a problem.  IMHO it is better to just leave things alone.

AFAIK there is no way to do this on 32-bit Arm.  I haven't looked into
other architectures, and given the limited utility I don't plan to.  I
am happy to accept patches if someone figures out a good way to do it
on other architectures.

This isn't complete, it's just to the point I got tired of working
on it.

XOP was an AMD ISA extension which Intel never adopted.  It is present
on heavy-equipment CPUs (bulldozer, piledriver, etc.), but no longer
supported on Zen.  It never really attained widespread use, but this
could still be useful.

Huge thanks to Jan Ringoš (@tringi) for testing this during
development; I don't have access to any hardware that supports XOP
so Jan's involvement was absolutely critical.

This is just the portable version; we still need to go through and add
accelerated implementations.

Fixes #678

The vector types have alignment requirements, but these functions are
specifically for storing *unaligned* data.  Some compilers (such as
clang 11) have started to generate bad code for the old versions, but
switching over to void* fixes that.

This also moves the _mm_loadu_epi{8,16,32,64} functions from AVX-512
over to SSE2 (for 128-bit) and AVX (for 256-bit), effectively replacing
the simde_x_mm*_loadu_* functions which are now simply aliases for the
AVX-512 functions.

The only real issue here is that our loadu_si* function take a void*
instead of a __m128i* or __m256i*, making them more permissive.  Code
written against SIMDe will allow you to pass, for example, int8_t* data
to these functions without warning, whereas the _loadu_si* functions
will likely trigger a diagnostic.

The solution for this is for code using SIMDe to call functions like
_mm_loadu_epi8 instead of _mm_loadu_si128, even if they don't want to
use AVX-512.  On SSE2, this will simply become a cast and call to
_mm_loadu_si128 and all is good.  On other architectures we avoid
undefined behavior becous void* has no alignment requirements.

That means the only *real* problem is code which ifdefs SIMDe usage.
In C I would suggest casting to void* instead of __m128i* or __m256i*
when calling _mm_loadu_si128 or _mm_loadu_si256; everything will work
as expected.  In C++, though, that will still generate a warning…
probably the best (well, least bad at least) solution there would be
to define a macro to use instead of _mm_loadu_si128/_mm256_loadu_si256
and use an ifdef to define it differently depending on whether you're
using SIMDe or not.

Fixes #691

This allows us to to only include it from files which really need
it (of which there aren't many; currently only SVML), which is
important since it can pull in a lot of extra headers and dramatically
increase compilation time.

Fixes #693

For value outside of (INT32_MIN, INT32_MAX), as well as NaNs, x86
returns INT32_MIN.

I added a SIMDE_FAST_CONVERSION_RANGE macro (which is defined by
default if SIMDE_FAST_MATH is defined) to opt-out of the more accurate
behavior since it's also substantially slower on many platforms.

Fixes #685