Initial infrasctructure for preconditioners

[mtanneau]

cc @amontoison

This PR introduces infrastructure for using preconditioners in conjunction with Krylov-based linear solvers.
The overall scheme is as follows:

• An AbstractPreconditioner type is introduced, from which preconditioner implementations should derive.
  Since preconditioners will be updated at each IPM iteration, persistent data structures make sense here.
  For instance, to hold and update limited-memory factorizations.
• Preconditioners are updated by calling update_preconditioner(kkt::AbstractKrylovSolver)
• KrylovKKTSolvers will have a field P that stores the preconditioner and, to ensure type stability at solve time, KrylovKKTSolver types will be templated by the type of P.
  !!! The limitation of this approach is that the type of preconditioner cannot be changed during the optimization. For instance, it would not be possible to start with a Jacobi preconditioner, then switch to a limited-memory factorization. More specifically, doing so would require a "meta-preconditioner" that switch between the
• A function op(P::AbstractPreconditioner) shall be implemented, that returns a linear operator which can then be passed in the Krylov method.

Overall, the code will thus look like this:

function update!(kkt, θ, regP, regD)
    # ...

    # Update preconditioner
    update_preconditioner(kkt)

    # ...
end

function solve!(dx, dy, kkt, ξp, ξd)
    # ...

    # Fetch preconditioner operator
    opM = op(kkt.P)

    # Solve normal equations
    _dx, stats = kkt.f(opS, ξ, M = opM, ...)

    # ...
end

Finally, the current way of selecting a preconditioner is through the preconditioner::Symbol key-word argument in KKTOptions.
Only :Identity and :Jacobi are supported at this time, and I only implemented them for the normal equations system, i.e., KrylovSPDSolvers.
This way of selecting preconditioners is not type-stable, and it will likely be changed in in favor of a factory-like approach, similar to the way KKTOptions are handled.