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.

ger and gemv call blas_memory_alloc/free which in their turn
call blas_lock. blas_lock create thread contention when matrices
are small and the number of thread is high enough. We avoid
call blas_memory_alloc by replacing it with stack allocation.
This can be enabled with:
make -DMAX_STACK_ALLOC=2048
The given size (in byte) must be high enough to avoid thread contention
and small enough to avoid stack overflow.

Fix #478

Add a CBLAS interface for the BLAS extension s/d/c/z*matcopy routines.

Signed-off-by: Timothy Gu <timothygu99@gmail.com>