Make SparseArrays an extension package

[ChrisRackauckas]

While this may seem a bit weird since the most normal case for Krylov subspace methods is on sparse arrays, there are multiple reasons for this.

1. SparseArrays pulls in SuiteSparse and thus GPL dependencies
2. This is by far the biggest part of the load. Normal Krylov.jl loads in about 8ms, but the SparseArrays part is ~150ms. So if you want to just work on operators, then you'd taking a decently sized hit.
3. This is required for downstream dependency reduction WIP: Make SparseArrays an extension SciML/LinearSolve.jl#570

[codecov]

Codecov Report

Attention: Patch coverage is 98.14503% with 11 lines in your changes missing coverage. Please review.

Project coverage is 93.37%. Comparing base (9536ef7) to head (4b547d6).
Report is 37 commits behind head on main.

Files with missing lines	Patch %	Lines
src/krylov_processes.jl	0.00%	8 Missing ⚠️
ext/KrylovSparseArraysExt.jl	99.48%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #955      +/-   ##
==========================================
- Coverage   94.68%   93.37%   -1.31%     
==========================================
  Files          45       48       +3     
  Lines        8027     9164    +1137     
==========================================
+ Hits         7600     8557     +957     
- Misses        427      607     +180     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[amontoison]

Is not LinearAlgebra the biggest part of the load?
It's fine for me to do an extension, I just want to be sure to document the need of doing using SparseArrays if the users want to call a Krylov process or a block-Krylov process.
We also want to update the compat entry on Julia (1.6 --> 1.10).

I can take care of that next week and do a new release.

[ChrisRackauckas]

LinearAlgebra.jl is a big one, that one will take a bit more time. The goal is to get the whole SciML stack to have sparse support optional first. I'm not sure a LinearSolve.jl without Linear algebra is possible without a refactor of the interface so we can get the types and the norm function separate, but that might be a Julia v1.13 thing