Add bidiagonal cholesky version

[dkarrasch]

This adds a generic version of cholesky for tridiagonal matrices. This fixes #1383, and massively boosts performance both for (Sym)Tridiagonals. Previously, we haven't had a kernel for the symtridiagonal case.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.87%. Comparing base (16f64e7) to head (d1978ef).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1409   +/-   ##
=======================================
  Coverage   93.86%   93.87%           
=======================================
  Files          34       34           
  Lines       15830    15852   +22     
=======================================
+ Hits        14859    14881   +22     
  Misses        971      971           

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

[araujoms]

Getting the generic version is even better than just calling pttrf, but isn't that worth it for BlasFloat?

[dkarrasch]

Thanks for your review. That was helpful!

Getting the generic version is even better than just calling pttrf, but isn't that worth it for BlasFloat?

I'll need to benchmark that.

[dkarrasch]

So, to give an update: I replaced the LAPACK-call to the ldlt-routine by the Julia code that we use in the ldlt-module. Apparently, we don't reach out to LAPACK for that either, even though pttrf! exists. I merged that loop with your corresponding two lines map!(sqrt, d); e .*= d. For Float64, performance is the same as in the last but one commit with the explicit LAPACK calls, which is faster than my initial simple "reduction of the dense algorithm". The reason, after all, for that is that we want to be able to avoid throws when check=false, which would be impossible with the LAPACK call.

[araujoms]

It would be possible to edit the pttrf wrapper, as it was done with the potrf wrapper, but since the performance is similar it's better to avoid a ccall anyway.