For #1416 and #1529, more information about the options OpenBLAS was built with is needed. Additionally we may want to add this data to the openblas.pc file (but not all projects use pkgconfig, and as far as I am aware the cmake module for accessing it does not make such "private" declarations available)

Change-Id: Id3fa4e8d9eedd4ef7230df69b611e7f397301a42

Change-Id: Ic896276cd073d6b41930c7c5a29d66348cd1725d

Catch invalid cpu count returned by CPU_COUNT_S

mips32 was seen to return zero here, driving nthreads to zero with subsequent fpe in blas_quickdivide

Allow building on OpenBSD

With this change, OpenBLAS builds and all tests pass on OpenBSD 6.2
using Clang. Tested on x86-64 only, with and without DYNAMIC_ARCH=1.

Old gcc and clang do not handle constructor arguments, finally fix #875 as discussed there, using the fedora patch

to migitate performance problems caused by #1052 and #1299 as seen in #1461

Even if we're directly using the win32 threading driver and not pthreads,
pthread_atfork still works fine to register a pre-fork handler, and is
necessary to restore the threading server to a pre-initialized state.

Some Linux distributions (notably SuSE) have raised CPU_SETSIZE to 4096, apparently disregarding API limitations.
From #1348, the highest value to survive array initialization (on a desktop system) is 3232, and 1024 - which is the 
more usual CPU_SETSIZE limit, was demonstrated to work fine on an actual bignuma system.

Failures to obtain or attach shared memory segments would lead to an exit without explanation of the exact cause.
This change introduces a more verbose error message and tries to make the code continue without setting cpu affinity.
Fixes #1351

also replaces one verbatim sched_yield with the YIELDING macro for consistency as suggested in #1351

CMake improvements

... as the "allocation" code jumped to now does UNLOCK_COMMAND instead of blas_unlock

CMake Improvements

Add sched_getcpu implementation for pre-2.6 glibc

Fixes #1210, compilation on RHEL5 with affinity enabled

Before this commit, the "position < NUM_BUFFERS" loop condition from
blas_memory_free will be completely optimized away by GCC. This is
because the condition can only be false after undefined behavior has
already been invoked (reading past the end of an array). As a
consequence of this bug, GCC also removes the subsequent if statement
and all the code after the error label because all of it is dead.

This commit switches the loop condition around so it works as intended.