Feature/cmake

[cpviolator]

This PR is a major refactoring of the dsa110-xengine code. It serves as both an acceleration strategy for the existing dsa-110 project as well as a precursor to the future dsa2000 code. Some notable features have been added, elucidated here, along with some notes:

1. The library now uses CMake as the build system. This allows us to build and install seamlessly and easily on a variety of architectures, focussing now on LINUX operating systems. OSX and Windows are possible with a few tweaks and the addition of pure CPU based code. Dependencies are either linked at CMake time, or downloaded and built at compile time via CMake. OSX, Windows and Linux should be able to create and test algorithms on laptops, then push code that will run performantly on HPC machines. This is the aim for future PRs.
2. The test routines at the moment will serve as examples on usage, benchmarking, and code veracity. This will be separated as development progresses so that the tests only measure performance and test veracity. Examples will be constructed in a separate directory completely independent of the native CMake build system to demonstrate how to link to the library from an independent client application.
3. dsa100-xengine is now a library with an interface and installation procedure. One need only include the dsaX.h header in the client application (as well as linking to the dsaX library) to access its functions. This will be important for dsa2000's future workflow where multiple client applications may need to perform dsa Fast Time Domain operations.
4. dsa100-xengine now has purely a C++ compliant front end so that no client application need be CUDA aware. All function calls need to supply only a host data array, a host output array, and (eventually) a struct that describes how operation to be performed. Acceleration strategies will be requested by the client application, and dsa100-xengine will perform as instructed.
5. The C++ compliant front end (algorithms, BLAS operation, etc) allows us to configure the back end (CUDA, CPU, Magma, Cutlass, etc) as we desire. This gives us the freedom to write new algorithms and routines without having to be cognisant of how performance critical parts of the code are performed. In this PR, BLAS operations are ported to cuBLAS, but a variety of different back end choices are in the pipeline. Front end results should be unaffected to machine/library precision.

Some instruction on building and running this code can be found in the wiki page. Any feedback (regardless of how minor it is thought to be) is welcomed and appreciated. Below is a list of tasks the submitter believes are essential before merging with the master branch.

TODO list

• Verify that the refactored code produces bona fide data WRT dsa100 workflow
• Add Magma, CUTLASS, TCC, xGPU, OpenBLAS, and CPU functionalty
• Add Laptop (pure CPU) functionality
• Add CPU verification of GPU kernels
• Doxygen header files