Add an AVX512 enabled DDOT function

written in C intrinsics for best readability.
(the same C code works for Haswell as well)

For logistical reasons the code falls back to the existing
haswell AVX2 implementation if the GCC or LLVM compiler is not new enough

Add workaround for avx512 compilations on Cygwin

fixes #1708

fix blasabs for windows

dscal is a relatively simple function... make it more readable and 50% faster
by using C intrinsics and AVX512 support

Use the same transformation as was done to saxpy for daxpy

gives a low double digit performance increase

avx512 support fits nicely in the C+intrinsics code and gets a
speed improvement for vectors where the saxpy operation is not fully
memory bound

the intrinsics version of saxpy is more readable than the inline asm version,
and in the intrinsics version there's no reason anymore to ban inlining
(since the compiler has full visibility now) which gives a mid single digits
improvement in performance

Improves readability

do the same thing for SDOT that the previous patches did for DDOT; the perf gain
is in the 60% range so at least somewhat interesting

now that it's written in C + intrinsics it's easy to add AVX512 support
for DDOT

Intrinsics based code is generally easier to read for the non-math part
of the algorithm and it's easier to add, say, AVX512 to it later

makes the asm easier to read

Bugfix in #1713 for Windows (LLP64), where `blasabs` needs to be `llabs` rather than `labs` for the 64-bit API.

Now that the code is written in intrinsics it's relatively easy to add AVX512 support

intrinsics make the non-math part of the code easier to follow
than all hand coded asm, and it also helps getting ready for
adding avx512 support

Introduce blasabs macro and use it to switch between abs and labs for INTERFACE64

fabs -> fabsl

symbolic names for gcc inline assembly are much easier to read

Now that the kernel is written in C-with-intrinsics, adding
AVX512 support to this kernel is trivial and yields a pretty significant
performance increase

using intrinsics is a bit easier to read (at least for the non-math part of the code)
and also allows the compiler to be better about register allocation and optimizing the
non-math (loop/setup) code.

It also allows the code to honor the "no fma" flag if the user so desires.

The result of this change is (measured for a size of 16) a 15% performance increase.

And it is a step towards being able to add an AVX512 version of the code.

gcc assembly syntax supports symbolic names in addition to numeric parameter order;
it's generally more readable to have code use the symbolic names

Fixes two calls that were using `fabs` on a `long double` argument rather than `fabsl`, which looks like it is doing an unintentional truncation to `double` precision.

Set EXPORT_NAME to match OpenBLASConfig.cmake

Haiku supporting patches

Fix #1705 where we incorrectly calculate page locations.

Since we now use an allocation size that isn't a multiple of PAGESIZE, finding
the pages for run_bench wasn't terminating properly.  Now we detect if we've
found enough pages for the allocation and terminate the loop.

Do not treat WIndows UWB builds as cross-compiling

Unset memory table entry, not just the local pointer to it on shutdown

to fix crash with multiple instances of OpenBLAS, #1692

Temporarily disable special handling of OPENMP thread memory allocation

for issue #1673

Add cpu identification via mfpvr call for the BSDs

Work around utest failures in the MIPS64 SICORTEX target