This is MicMuc's patch from #899

* fix unlikely memleak in zimatcopy interface

* fix only unlikely memleak in zimatcopy interface

* fix only unlikely memleak in zimatcopy interface

* 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.