Solvers are now classes, but many things are expecting CreateSolverType functions

[juropo]

What is the current behavior?

• Solvers were relatively recently updated to be classes, that all seem to implement an init function and a solve function, which is called when the problem should be solved.
• This change is not reflected in many other parts of the code base.
• tools->generics.py still only defines CreateSolverType which is a callable that returns a callable and not a class. There is no generic definition for what a solver class looks like.
• Other code uses the CreateSolverType. For example, tools->utils.py->guess_best_solver claims it returns a CreateSolverType, but in reality returns one of the solver classes. This may cause errors with whatever code uses this function.
• Some of the solvers' init functions claim in the docstring that they return CreateSolverType.

Describe the solution you'd like

• Remove the CreateSolverType and add SolverType (or something) that tells what other code can expect from the solvers.
• Fix all the errors that result from removal of CreateSolverType by updating the code to use the solver classes.

What is the motivation/use case for changing the behavior?

• Right now, what the code does does not match the type hints and documentation, so something needs to be changed.

Describe alternatives you've considered

• An alternative could be to implement some kind of function that adheres to the format of CreateSolverType and that will initialize solver classes and return pointers to the solve() functions within them. This seems unnecessarily convoluted.
• The other alternative would be to reverse solvers back to functions that return functions instead of classes, but there was a reason why this change was made.

Additional context

• This involves going through a lot of code, but is not especially difficult to do.
• We should maybe consider whether solver classes by default should implement some other functions as well, or if just having init and solve functions is enough.