`init/solve` structure, solver caches, tests, naming

Sorry for all the spam (let me know if I should write fewer issues) 😝

Here are some ideas for next steps. (Obviously, you have more experience, I'm happy to get advice). We could

• introduce the classical init/solve structure
• add more tests, especially for AD
• caches for algorithms

For me, especially tests would be helpful as I don't have a good idea of what kind of inputs/interfaces we can assume.
For example, in the linear case, do we only assume a linear AbstractSciMLOperator? Do solvers need to be compatible with Duals? (or will the differentiation always be handled externally, like currently in adjoint.jl which seems mostly algorithm independent).

A few minor things:

• Naming conventions: For linear problems, it seems that the initial guess is called u0, which is confusing since in the solution type it is called z. Would it be an option to rename it to z0? On the other hand, for the mixed and nonlinear case u is maybe a better variable name. So, one could either always call the unknown u (linear/mixed/nonlinear) or have z (for linear) and u (for mixed/nonlinear).
• Tolerance and error estimates: I added error_estimate for the PSOR type solvers. In general, it would be nice to have a common way to set the tolerance of an algorithm. Should it be reltol/abstol or just one tol parameter?
• The field residual feels to be a bit ambiguous. Different algorithms might have different choices for the residuals (depending on the nonlinear functions). Should it return NaN if an algorithm has no residual for an algorithm (like for PSOR) or should it be an error estimator in that case?

Start by reviewing the current solver entry points and adjoint.jl, then compare how PSOR and other algorithms handle initialization, tolerances, residuals, and error estimates. The issue does not name specific implementation or test files; define the intended interfaces and scope before changing code, with init/solve structure, cache behavior, naming, and coverage agreed as done.