* Hopefully, because this was found by error and trial (dark magic)
* Ref #786

added experimental support for optimized lapack fortran functions

If OpenBLAS is built using add_subdirectory(OpenBlas) as part of another project
then the paths set by CMAKE_XXX_DIR are relative to the parent project
and not the OpenBLAS project.

* Close #873

* Use stack allocation
* Disable multi-threading
* Ref #727

For better performance with small matrices
Ref #727

...not a matrix size. For GEMM_MULTITHREAD_THRESHOLD=4
(the default value) this does not change anything but
for other values it make the GEMM and GEMV thresholds
changing in the same way.

Close #742

The ones given in 3ae30cd was by far to low because I
mixed m and m*n in my measures. Note that the new ones
are closed to the [z]gemv ones which is comforting
that both are right.

Close #731

Ref #731

Ref #727

Close #722

Thank matzeri's patch.

Conflicts:
	driver/others/memory.c

Conflicts:
	driver/others/memory.c

The Ximatcopy functions create a copy of the input matrix
although they seem to work inplace. The new routines
XIMATCOPY_K_YY perform the operations inplace if the leading
dimension does not change.

Disable CBLAS and LAPACK.

Ref #478

For gemv_t, directly use malloc to create the buffer.

Instead of generating separate object files for each permutation of
defines for a source file, GenerateNamedObjects now writes an entirely
new source file and inserts the defines as #define c statements.

This solves a problem I ran into with ar.exe where it was refusing to
link objects that had the same filename despite having different paths.

There are a lot of sources for complex float types that are the same
names as the real sources, except with z prepended.

This will generate obj files for SINGLE/DOUBLE/COMPLEX/DOUBLE COMPLEX.

It sets DBLAS_OBJS directly to save a bunch of list appending in the
CMakeLists.txt files.

The BLAS interface folder should now be generated the correct objects
for the DOUBLE case.

Naming isn't right, though, not seeing cblas_xxxx exports in the
resulting library.

* stack_alloc_size is needed after the implementation call
but it may be overwritten if it's optimized to a register,
because some gemv implementation (ex: dgemv_n.S) do not
restore all register (ex: r10).
* do the same in ger.c for the same reasons even if the bug
has not been observed.

It only does the double precision compile currently.

I realized I didn't finish converting Makefile.system yet, so I made
a note of that.