mat: rewrite extractions and solves as methods on factorising types

[kortschak]

@btracey Please take a look.

Fixes #101.
Fixes #102.

[btracey]

Here's a meta comment, just to make sure I'm thinking about this correctly in the code review.

I would love to figure out how to make higher-level libraries be efficient with their use of matrix types. Let's say (in a future gonum), we have var a mat.Diag, and we have filled in a. I would love if cholesky.Factorize just takes the square root of the matrix entries and stores a diagonal matrix. This could happen, for instance, in distmv.Normal, passing in a diagonal covariance matrix (very common).

I believe moving the Solve routines into Cholesky allows this. Cholesky can somehow maintain the inner matrix type, and so when we call chol.SolveVec, we can call the diagonal SolveVec routine (which would be trivial). Similarly, by providing a chol.MulVec, we have now reduced all operations on Normal from N^3 to just O(N), a huge speedup.

I also think if we do this properly, this opens the door for really nice interoperability with sparse matrices. For instance, our current linear programming implementation forces using dense matrices, which means it'll never compete with "real" lp solvers. But, we could create some interface that's like

type LPMatrix struct {
      SolveVec(v, b *Vector) error
      MulVec(a,b *Vector)
}

This interface can now be implemented by Cholesky (for Dense LPs, or structured sparse LPs), and then by some outside/future package that provides those routines for a sparse matrix and Cholesky decomposition.

This is the opportunity I think we can provide with a potentially huge benefit. I'd like to see if we're on the same page.

[kortschak]

Moving the methods onto the factorising types I don't think changes this (first and second part), but can be used for the lp part. My main motivation is just ease of legibility. Note that there's another sweep that needs to go through that allows many of these methods to take nil and allocate returning the result. Also, I think Cholesky.To may want to be called ToSymmetric. What do you think? Finally, with the addition of the band types, we get diagonals for free, so that can just be type switched in the appropriate places.

[vladimir-ch]

Please unify the name of the receiver.

[kortschak]

Thanks. Done.

[kortschak]

I have not made errorable methods (inverse and solve) able to allocate a destination and return it. This can be done later if people want it.