Improving factory parameters

[upsj]

I think the current factory parameter setup could use with a few improvements:

• The factory parameters generated by our macros are mutable by default! That's a big code smell IMO, though we can't change it without potentially breaking user code (fixed by make the type in deferred_factory more explicit #1439)
• The factory parameters get injected into the generated LinOp by default. That means that we need to carry them around and cannot discard them after generation, which may be useful in some cases, like solvers, where we no longer need the preconditioner factory after generation. Again, this can't be changed without an interface break.
• The fluent interface with_parameter is templated and forwards its argument(s) into a brace-initializer. That means that a parameter of type unsigned can't be initialized with an argument of type int.
• The current design assumes that there is a 1:1 relationship between LinOpFactories and LinOps. That is a strong limitation, as there are many cases where it makes sense to use a variety of different algorithms (= factories) to generate the same kind of object, e.g. factorizations. Add sparse direct interface #1082
• Redundancy: We specify the same stopping_criterion, preconditioner, initial_guess, logger for all iterative solvers. What if we built a factory parameter type hierarchy that mirrors the underlying solver hierarchy? That way, users have a single place where to look up how to set up a solver, and we only need to maintain a single piece of documentation. Most solvers will not need any additional parameters, and the ones that do will only need a handful of parameters, like the restart in GMRES. Handled by Factory improvements #1336
•  Potentially it might make sense to decouple the fluent interface more from the parameters, to allow different ways of specifying the same parameter or similar.

As a first step, I built #1082 with suggested fixes for most of these issues in mind.