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.