Add support for block sparse QR decomposition

[mtfishman]

Closely related to the implementation of block sparse SVD in #111.

Note that it still needs to be generalized to accomodate graded arrays similar to #114, I'll wait for that PR to get merged so this can share tools and code designs of that PR.

To-do:

• Generalize to accomodate graded arrays like in Make SVD more general to accommodate graded arrays #114 and Make SVD a bit more customizable #121.
• Add tests.

@lkdvos the implementation is very similar to #111 so it makes me wonder if we can combine them in some way but that might be tricky.

Here's one potential approach: the QR decomposition here has the same block pattern as doing the factorization (U, S * V), so maybe there could be a single code that factorizes into (X, Y) where in the SVD case Y has blocks Y_b that lazily store the pair (S_b, V_b), which could then get split apart in a final step.

[codecov]

Codecov Report

Attention: Patch coverage is 84.32836% with 21 lines in your changes missing coverage. Please review.

Project coverage is 76.28%. Comparing base (2120b7a) to head (0b157d1).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/factorizations/qr.jl	84.32%	21 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #117      +/-   ##
==========================================
+ Coverage   75.45%   76.28%   +0.82%     
==========================================
  Files          29       30       +1     
  Lines        1308     1442     +134     
==========================================
+ Hits          987     1100     +113     
- Misses        321      342      +21     

Flag	Coverage Δ
docs	11.96% <0.00%> (-1.24%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

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

[lkdvos]

I think that indeed, once the other PR is merged and the same changes are used here this is exactly how I would also do this.

Considering the code reuse, it might be possible to factor out some of it, but the more I look at it, the more I'm noticing small differences that would make it quite unelegant to try and merge all of the implementations together, in the sense that I'm expecting that the small differences would lead to many small if statements, which might actually make things more complicated to maintain in the long run. This is obviously just a feeling, and I might be wrong about this, but it also seems like the consequences of either option aren't that big

[mtfishman]

Considering the code reuse, it might be possible to factor out some of it, but the more I look at it, the more I'm noticing small differences that would make it quite unelegant to try and merge all of the implementations together, in the sense that I'm expecting that the small differences would lead to many small if statements, which might actually make things more complicated to maintain in the long run. This is obviously just a feeling, and I might be wrong about this, but it also seems like the consequences of either option aren't that big

Yeah, that's one of my concerns as well. Probably block permuting to block diagonal as we discussed is the best way to go to share functionality across block sparse factorizations.