Max-ones argument and more detailed error reporting

I've added a couple minor features:

1. A check to make sure that the ones matrix is large enough to do a particular sum.
2. A keyword argument to set the size of the ones matrix during cublas_init if desired.
3. More detailed cublas error reporting (which mirrors the cublas errors in CUDA 6.0)
Hmm, I think the functions in `cudamat.cu` should return error codes, and `cudamat.cu` should provide a function to translate error codes to strings which can be called from Python.
The problem with this is not so much that CUDA errors overlap with CuBLAS errors, because most functions either call cublas or launch a cuda kernel, but not both, so the Python code can treat the result appropriately. However, several functions can both return a CUDA/CuBLAS or a cudamat error such as "Matrix not on device", "Transpose error" -- in this case we cannot define the function to return a `cudaError_t` or `cublasStatus_t`, but need to roll our own.

One solution would be calling `cudaPeekAtLastError()` to see if anything went wrong CUDA-wise, returning the cudamat-specific `CUDA_ERROR` and requiring the Python code to obtain the actual CUDA error code and translate it into an error string via `cudaGetLastError()` and `cudaGetErrorString()`. But as you said, this would be a little hacky, it might get us into trouble when doing multi-threading or multiple streams, and there is no such mechanism for CuBLAS.

The cleanest solution would be raising the proper Python exception from within the C code, but then we would need to build `cudamat.cu` as a Python module rather than wrapping via ctypes. That's probably too much work.

So defining our own, but more specific error codes will be the best solution. Let's see, what are the possible errors anyway?
For CUDA, we currently have [an enum with codes from 0 to 77 and 0x7f](http://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__TYPES.html#group__CUDART__TYPES_1g3f51e3575c2178246db0a94a430e0038).
For CuBLAS, we currently have [an enum](http://docs.nvidia.com/cuda/cublas/index.html#cublasstatus_t) with [codes from 0 to 14](http://stackoverflow.com/a/13041774) that hasn't changed for a long time.
For cudamat itself, we currently have [integer constants from -1 to -9](https://github.com/cudamat/cudamat/blob/master/cudamat.cuh), but `CUBLAS_ERROR` and `CUDA_ERROR` would be dropped, `VIEW_ERROR` and `ERROR_UNSUPPORTED` are unused, `ERROR_GENERIC` is just used once, leaving us with 4 and a half useful error codes.
We could leave error codes as ints (as they are now), mapping all positive values directly to CUDA errors, all negative values up to -100000 directly to CuBLAS errors, and values smaller than -100000 to custom cudamat errors. When CuBLAS invents new error codes, we just need to ensure they don't clash with our custom errors and move them farther away if needed.

For the exceptions, we could stick with a single class that stores our custom error code and a message, or we could have cublas-, cuda- and cudamat-specific exceptions that store the original error code, all derived from a common exception class so it's easy to (a) catch all exceptions that come from cudamat and (b) catch specific exceptions and use the error codes to distinguish them.

Any comments/ideas?