[RFC] Symplectic Arnoldi

[simeonschaub]

See the discussion in #150. On my test case, this already gives me
significantly better performance, and improved accuracy, if using
re-skew-orthogonalization, than my hand-rolled Arnoldi implementation. An initial sketch was written by Copilot, but
I revised and reviewed the result extensively.

closes #150

[github-actions]

Your PR no longer requires formatting changes. Thank you for your contribution!

[codecov]

Codecov Report

❌ Patch coverage is 75.14451% with 43 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.93%. Comparing base (03fa163) to head (39ea122).

Files with missing lines	Patch %	Lines
src/orthonormal.jl	71.84%	29 Missing ⚠️
src/innerproductvec.jl	72.00%	7 Missing ⚠️
src/factorizations/arnoldi.jl	86.11%	5 Missing ⚠️
src/algorithms.jl	75.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #151      +/-   ##
==========================================
+ Coverage   86.61%   87.93%   +1.31%     
==========================================
  Files          36       36              
  Lines        3901     4077     +176     
==========================================
+ Hits         3379     3585     +206     
+ Misses        522      492      -30     

☔ 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.

[simeonschaub]

Ok, I think I am happy with the implementation now from my side. This should enable some initial experimentation with symplectic Gram-Schmidt methods. Future work might include blocked methods such as described in https://journal.austms.org.au/ojs/index.php/ANZIAMJ/article/view/9380/1920, but I don't want to make this PR much bigger than it already is.

[Jutho]

Ok, I will have to study this a bit further and let it sink in, but my initial impression is that I am not a big fan of "recycling" inner and InnerProductVec for computing the symplectic form, which than results in hacky solutions such as having to introduce a separate norm and a standard_dot function. While I agree that could duplication is typically harder to maintain, in this case I wouldn't mind if the symplectic functionality is provided through a separate SymplecticFormVec that copies a lot of the functionality of InnerProductVec, and uses a new dedicated sympleticform (or other shorter name) primitive for applying the symplectic form. I prefer the mathematical correctness of such an approach (inner and symplecticform have fundamentally different behavior under interchanging the two arguments), and think that will lead to cleaner and easier to comprehend code.