Cosmetic changes to the proof of Thm 3.6.
Replace "ldots" and "cdots".

This commit replaces the graphical "ldots" and "cdots" commands
for lower and centred dots with the more semantic commands
"dotsc" (for comma-separated lifts), "dotsm" (for multiplicative
dots) and "dotsb" (for addition-like operations).  The commands
do not only place the dots at the right height but also assure
appropriate spacing.
Fix an overfull box in Prop 3.7.
Cosmetic improvements to Algorithm 3.3.
Fix Remark 3.12.

I have made Remark 3.12 more precise, but also weakened it.  In short,
it is not really necessary that one is working with square matrices,
I think.  In general, I don't see a reason why one couldn't solve
sparse rectangular systems A x = b repeatedly, also taking advantage
of some LUP-decomposition like preprocessing.  That said, it's all a
bit easier (conceptually!) when you are working with square matrices.
The code is easier to write, and from a theoretical point of view you
have existence (which you have anyway from Macaulay's result) and
uniqueness of the solutions, so you don't have to worry about which
solution of the linear system you pick in order to reduce the pole
order.

I have currently also removed the one sentence about sparse matrices
here.  For ad hoc examples, the sparsity is really important, of course,
and eventually the code should definitely be written in a gradual approach
whereby one solves the remaining blocks sparsely while they are sparse and
moves to a generic dense approach once they become dense.  But it's hard
to be formal about that in a small remark, and it's harder still to find
good references:  In my transfer thesis, I simply cited Duff and Reed from
the 70's, which, let's face it, is a little old.  But if you do a search
for sparse matrix methods, almost all papers will be from physics or
operational research, and will be full of assumptions on the structure
of the matrices (band diagonal, positive-definite, symmetric, etc) and the
element type (32 or 64-bit double).

And, to answer the TODO marker which you've left:  No, the inverse of a
sparse matrix does not have to be sparse at all.  If you can make some
structural assumptions, this sometimes changes.