[eigen] Organization of the sparse module(s)

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

Hi,

I'm in the process of moving the few sparse solvers currently spread
in the unsupported folder into official Eigen/ folder. So the question
is about the granularity of the module I'll create for that. For
consistency reason, the Sparse module should include everything that
is related to sparse and built-in. "Support" modules have to stay into
isolated modules. Here is the list of features with a proposal for an
organization:

* SparseCore *
- representation, manipulation,
- coefficient-wise operations, products (sparse-sparse, sparse-dense,
sparse-permutation),
- triangular solvers
- ordering methods (currently AMD=approximate minimum degree only)

* SimplicialFactorizations *
- direct LLT and LDLt decompositions and solving for SPD sparse matrices,
- two classes: SimplicialLLt and SimplicialLDLt
- future: direct simplicial LU and QR factorization and solver

* IterativeLinearSolvers *
- ConjugateGradient (Iterative solver for Ax=b with A SPD)
- BiCGSTAB (Iterative solver for A square)
- Basic preconditioners:
  - IdentityPreconditioner
  - DiagonalPreconditioner (= Jacobi preconditioner)
  - future: SSOR, ILUT

Three support modules:
* SuperLUSupport *
* CholmodSupport *
* UmfPackSupport *
future: MumpsSupport, PastixSupport, MetisSupport, ScotchSupport, etc.


Future could add some new modules:

* ConstrainedLinearSolvers *
 - for both dense and sparse worlds

* <a generic word for multifrontal and supernodal>Factorizations *
 - Fast direct LLt and LU factorizations based on supernodes or
multifrontal approaches (automatically make use of dense matrix
operations)

Any opinion about this granularity? Another options for the direct
solvers would be to organize them into three modules:
DirectSparseCholesky, DirectSparseLU, DirectSparseQR.


cheers,

gael