Remove StridedArray restrictions on factorization objects.

[dlfivefifty]

I'm going through the QR, Cholesky, etc. factorization codes as I re-write the factorizations in BandedMatrices.jl (and elsewhere) to be consistent with Base, and there are a large amount of unnecessary restrictions to StridedArrays. This is particularly silly as many of the factorizations have generic Julia fallbacks which do not use strided-ness at all.

I can do a PR when I get some time.

[dlfivefifty]

And we also need to add restrictions to StridedArray where LAPack is called, here is an example:

https://github.com/JuliaLang/julia/blob/8c0b550b61bcb196e1c8a9b03b38f0e6eb8a9dd7/stdlib/LinearAlgebra/src/cholesky.jl#L398

[mbauman]

You may find JuliaLang/julia#31149 helpful as you go through these — I use it semi-regularly when dealing with method lists that are ridiculous. I've not merged it since nobody has reviewed or voiced their support for it.

[andreasnoack]

This is particularly silly as many of the factorizations have generic Julia fallbacks which do not use strided-ness at all.

I completely agree for some of the "outer" functions which only converts to the right element type but I have more mixed feelings for the actual implementations. While the generic implementations don't use the stridedness of StridedArrays explicitly, restricting to StridedArray ensures the elementwise access to the array is not prohibitively slow. Hitting a generic dense linear algebra routine with a sparse or distributed arrays is quite frustrating.

[dlfivefifty]

We could overload for AbstractSparseArray to throw an error

[andreasnoack]

We could overload for AbstractSparseArray to throw an error

Something like might end up as the solution. GPUArrays and now also DistributedArrays have a flag to disallow scalar getindex to make it easier to detect when you hit AbstractArray implementations that fetch elements one-by-one.