fix!: revamp linear operator handling

[gdalle]

Caution

Breaking changes in the public API. Bumping version to v0.8.0.

Breaking changes

• Rename KrylovLinearSolver into IterativeLinearSolver
• Enforce strict behavior with DifferentiationInterface, with an option to relax it
• Specify correct vector type in the LinearOperator definition, leading to errors with ComponentArrays
• Make B a function instead of a linear operator or matrix

Other changes

• Allow specifying different backends for differentiating conditions with respect to x and y
• Allow the use of LinearMaps + IterativeSolvers instead of LinearOperators + Krylov

Internal changes

• Switch to TestItems for testing
• Add compat deps

[codecov]

Codecov Report

Attention: Patch coverage is 99.14530% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/implicit_function.jl	93.75%	1 Missing ⚠️

Files with missing lines	Coverage Δ
ext/ImplicitDifferentiationChainRulesCoreExt.jl	95.00% <100.00%> (+0.26%)	⬆️
ext/ImplicitDifferentiationForwardDiffExt.jl	100.00% <100.00%> (ø)
src/ImplicitDifferentiation.jl	100.00% <ø> (ø)
src/execution.jl	100.00% <100.00%> (ø)
src/preparation.jl	100.00% <100.00%> (ø)
src/settings.jl	100.00% <100.00%> (+7.69%)	⬆️
src/implicit_function.jl	88.88% <93.75%> (+0.88%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[amontoison]

LinearMaps also works with Krylov.jl. What is the reason to support IterativeSolvers.jl? For information, the GMRES method is only restarted in this package.

[gdalle]

To me it made sense to support both ecosystems: LinearMaps + IterativeSolvers and LinearOperators + Krylov, since they were both designed to work best with each other.

[amontoison]

To the best of my knowledge, Krylov.jl was modified since a few years to work with both API the same way.
Be careful if you use solvers IterativeSolvers, a few of their solvers have bugs...
SciML/LinearSolve.jl#181

[gdalle]

Good to know. Judging by number of stars and seniority I thought they were both valid alternatives.

[gdalle]

Essentially my reasoning was: due to some type issues, I sometimes need LinearMaps instead of LinearOperators. In that case, I should pick the solver that goes best with LinearMaps, and I thought that was IterativeSolvers