Overview
--------
This is a collection of design notes that should eventually wind up in
the documentation. I'm just not sure where they go yet.

Matrix representations
----------------------

Why allow matrix representations for all algebras?

1. We already have a to_vector() operation that turns an algebra
element into a vector whose coordinates live in the algebra's
base_ring(). Adding a to_matrix() operation is a natural
generalization of that.

2. When constructing a Cartesian product algebra, we don't know a
priori whether or not the result will have matrix-algebra factors. We
can figure it out at runtime, but it would be nice if DirectSumEJA
always returned the same class. Maybe more importantly, if a Cartesian
product has one matrix and one non-matrix factor, then what would its
own matrix representation look like? We want to delegate to the
factors...


Basis normalization
-------------------
For performance reasons, we need a class (RationalBasis...) that
orthonormalizes its own basis. We *could* insist that the user do
this, of course, but the reason we don't want him to is because we
need to know how to undo the process. If we run Gram-Schmidt on the
basis matrix ourselves, then we can save the matrix that undoes the
process. And by undoing the process, we can get to a basis where
computations are fast again.

Question: what's the best way to construct these algebras? We'll
usually know,

  * the multiplication function
  * the inner-product function
  * a basis in either vector or matrix format

and want:

  * an orthonormalized copy of the basis, in long-vector format
  * the reverse gram-schmidt matrix that deorthonormalizes that
    long-vector basis
  * a multiplication matrix (for speed) w.r.t. the orthonormal basis
  * an inner-product matrix (for speed) w.r.t. the orthonormal basis
  * a way to turn those two matrices into multiplication and inner-
    product matrices for the deorthonormalized basis.