Resulted in some complaints of -fsanitize=undefined

Thanks to AddressSanitizer in GCC 4.9

-Wall -Wextra -pedantic -Wconversion.
A tricky detail is that the product of two chars or shorts gets
promoted to 'int', so some extra logic was required.

Issue introduced here: 4ebc5c60

Resolves #112 (together with previous commit).

This is in response to issue #112, which reports that the use
of OpenMP-'variables' derived from templates is unspecified/undefined.
Problems have been observed with the Fujitsu compiler.

Resulted in complaints if called from GMRES, therefore passing it in as a pointer.
Should not affect performance, but verification desired.

Without these, some user code may accidentally use the solvers
without pipelining, which is not what we want...

Although the original code is perfectly legal, we have to introduce
some preprocessor magic to solve this issue.

Used to be a reference, for which initialization with NULL doesn't work.
Now using copies, which is fine due to smart-pointer semantics.

This reverts commit
4381e000
for non-NVIDIA devices, providing better performance portability.

Use of thread-local variables is substantially slower than using
shared memory directly in this case. 2x difference on a Tesla C2050
for this particular kernel. Overall performance gains depend on sparsity
pattern of the matrix (as always).

This has been a problem if one wanted to use compressed_matrix outside the
default memory domain.

Results in mild (about 10 percent) performance gains.

Provides about 10 percent better performance on average for a
mix of typical matrices from the Florida Sparse Matrix Collection.

Based on experiments on a GTX 470. Kepler and Maxwell GPUs might
behave differently.

Warnings were due to conversion of floats to bools.

Introduced by 0ba719f3.

See paper "Efficient Sparse Matrix-Vector Multiplication on GPUs using the CSR Storage Format"
by Greathouse and Daga, presented at SC 2014.

Problems were only found in the matrix-times-matrix case.
Resolves #2.

Now a user can directly provide std::vector< std::map<IndexType, NumericType> >
to populate the sparse matrix. This was already possible for the other sparse matrix
types.

Resolves #6. A little bit of input-dependent tuning is certainly possible,
yet the overall control flow is now fixed. Performance largely dependent
on the performance of matrix-vector and matrix-matrix products, respectively.

Disable coveralls. Takes too long to run and hence fails.

Old generator tests and OpenCL random number generation. Both superseded.

lcov takes much too long making the travis builds time out and fail.