matrix/mat64: consider whether a row vector type should be added

[kortschak]

This comes out of discussion in #361. The answer is probably no, but I want to decide formally before API stability.

There is a need to be able to perform a dst.Copy(vec.T()) where vec is a vector shadowing the destination row in dst since vec represents a column vector, even when it is the result of a dst.RowView(i) call.

The problem in #361 is a result of this semantic abuse. A possible solution (proposed here) is to change the signature of RowView to RowView(int) *Row, ColView to ColView(int) *Col and derive Row and Col from Vector. Col becomes a method limited alias of Vector (both Col and Row must satisfy Matrix but needn't have the other methods. This adds a level of complexity since now rows or columns must be converted to a Vector for some operations and some operations will need to have additional type switch cases, but we can remove the exception for unitary stride in Copy goes away and the type system is more consistent.

[vladimir-ch]

It would bring its own set of implications but RowView and ColView could return a *Dense instead of *Vector.

[kortschak]

There still needs to be a way of getting a Vector from a Dense.

[kortschak]

Here is a sketch (minimal changes wrt method addition): https://github.com/gonum/matrix/commit/67ac476ec15bf010fc7bd1f7c16222c73dcfaf02

[btracey]

https://github.com/gonum/gonum/issues/167 is the new issue for this.