`MatrixHandler::matrixInfNorm` should not assume that the input matrix is in the csr format

[superwhiskers]

currently, the matrixInfNorm method of MatrixHandler and its corresponding implementation classes, MatrixHandlerCpu et al. (introduced in #102) incorrectly assume that the input matrix will always be in the csr format. this conflicts with the type signature, which indicates the matrix just has to be of the Sparse class.

this is bad for multiple reasons:

• users may incorrectly assume that it permitting the input matrix to be any Sparse matrix means it works for any such matrix
• this will silently fail on Coo matrices, as all of their rows/columns/values are large enough to accept being indexed that way
  • the error manifests as a performance problem that can be traced back to MatrixHandler::matrixInfNorm
  • this also results in incorrect data with a nonobvious source
• this will cause memory access errors when used on Csc matrices

this should be resolved by

• adding a disclaimer in the documentation about this (immediately)
• modifying the method by
  • not accepting just any matrix and specializing it to Csr or
  • generalizing it to work over different matrix formats

[pelesh]

Thanks for documenting this @superwhiskers!

[pelesh]

It should probably be specialized to Csr matrices. Support for other formats could be added later by function overloading, if needed.

[pelesh]

Best thing we can do in the short term is tp check if the matrix is CSR and return error, if it is not. It is unlikely that matvec and matrixInfNorm methods of MatrixHandler class will support any other format in the near future.

The quick fix is in #190.

The challenge here is that solver implementation should be agnostic of the matrix type. Because of that, MatrixHandler methods signatures should accept generic matrix::Sparse objects. However, implementation of MatrixHandler methods is specific to the matrix format.

CC @kswirydo @stonecoldhughes