Sloppy use of `gemv` in `GrammSchmidt` class.

[pelesh]

It seems that GrammSchmidt implementation can apply gemv to a subset of vectors in a multivector. Applying overzealous assert statements will render GramSchmidt class nonfunctional in the debug mode and cause multiple tests to fail. We need to document better how VectorHandler::gemv is used in GrammSchmidt class and add appropriate protections to the code that do not contradict the intended use of gemv functions.

Originally posted by @shakedregev in #411 (comment)

[pelesh]

This seems to be a bug in GramSchmidt class. For example, see this gemv call:

ReSolve/resolve/GramSchmidt.cpp

Lines 181 to 182 in 3d712ca

	vec_v_->setData(V->getData(i + 1, memspace_), memspace_);
	vector_handler_->gemv('T', n, i + 1, &ONE, &ZERO, V, vec_v_, vec_Hcolumn_, memspace_);

If I print number of matrix columns to include in the product (in this code this is i + 1) and matrix and vector sizes, at some point I get something like this:

(...)

size of V: 1843
num vecs in V: 201
size of vec_v_: 1843
size of vec_Hcolumn_: 1

i + 1 = 2
size of V: 1843
num vecs in V: 201
size of y vec_v_: 1843
size of x vec_Hcolumn_: 1

In the second case above k does not match the size of vec_Hcolumn_ . The mathematical operation is $H_{col} := V^T v$, where $V$ is $1843 \times 201$ matrix, $v$ is $1843 \times 1$ and $H_{col}$ is $1 \times 1$. Since i + 1 in this case is 2, the first two columns in $V$ will multiply vector $v$ and whatever is at the next 1843 memory locations. The correct result will be stored in $H_{col}$, but it seems to me that the next memory location will be overwritten. The capacity of $H_{col}$ is set to restart value so overwrite will be harmless until the point of restart.

In summary, this is a bug, which will rarely manifest itself. The usage of gemv function in the GramSchmidt class is sloppy and bug prone. The class needs to be refactored.

CC @kswirydo @shakedregev