Separate Algorithm and Driver

[lkdvos]

This is a start for tackling #176, while refactoring some of the QR/LQ implementation to share more code between the different backends -> drivers.

As usual, to keep this somewhat contained I only looked at QR/LQ decompositions to allow for some discussion first.
The next steps would be to include the SVD and eigenvalue decompositions in a similar manner.

From what I can tell, I managed to implement this in a non-breaking way, deprecating the previous *_Householder* structs without removing them.

[Jutho]

I think this looks good. Does this in any way give rise to conflicts with the whole algorithm selection mechanism via keywords and symbols?

[lkdvos]

Not really, I think mostly the alg is still there for the algorithm selection mechanism, which should then become alg = :Householder (which I will fix in a moment), while the driver is just an additional keyword argument that may or may not be there. I think in the end this is not changing all that much, just adding one more layer of delaying choices, based on the assumption that you probably don't want to change the driver, while it is more reasonable to try and change the algorithm.

[codecov]

Codecov Report

❌ Patch coverage is 85.93750% with 36 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/implementations/qr.jl	88.29%	11 Missing ⚠️
src/implementations/lq.jl	92.92%	8 Missing ⚠️
ext/MatrixAlgebraKitGenericLinearAlgebraExt.jl	68.42%	6 Missing ⚠️
src/common/householder.jl	28.57%	5 Missing ⚠️
...MatrixAlgebraKitCUDAExt/MatrixAlgebraKitCUDAExt.jl	33.33%	4 Missing ⚠️
src/interface/lq.jl	66.66%	1 Missing ⚠️
src/interface/qr.jl	66.66%	1 Missing ⚠️

Files with missing lines	Coverage Δ
...ixAlgebraKitAMDGPUExt/MatrixAlgebraKitAMDGPUExt.jl	65.90% <100.00%> (-6.10%)	⬇️
src/algorithms.jl	89.36% <100.00%> (-1.01%)	⬇️
src/interface/decompositions.jl	76.19% <100.00%> (+2.50%)	⬆️
src/interface/lq.jl	83.33% <66.66%> (+19.69%)	⬆️
src/interface/qr.jl	83.33% <66.66%> (+19.69%)	⬆️
...MatrixAlgebraKitCUDAExt/MatrixAlgebraKitCUDAExt.jl	62.96% <33.33%> (+2.02%)	⬆️
src/common/householder.jl	59.45% <28.57%> (ø)
ext/MatrixAlgebraKitGenericLinearAlgebraExt.jl	85.91% <68.42%> (-8.07%)	⬇️
src/implementations/lq.jl	95.02% <92.92%> (-2.17%)	⬇️
src/implementations/qr.jl	95.04% <88.29%> (-0.16%)	⬇️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[lkdvos]

So, I actually did manage to break the whole type stability chain in the LTS version. As a possible solution, I know just @assume_effects :foldable, but this does kind of mean that we are fighting the compiler a bit (which we were really already doing, with the @inline annotations everywhere).

@Jutho, @kshyatt , @mtfishman I'd like to hear opinions on this, I think this will save me a lot of annoyance in the long run, but might also lead to accidents if used incorrectly, so there is definitely some trade-off there