Exposing single precision support from MKL

[mipals]

• Exposing single precision support from MKL. Error in MKL Pardiso for single precision matrices #107
• Changing name of file from "project_pardiso.jl" to "panua_pardiso.jl".
• Adding check for square matrix. How to setting for solving A x = b with A in R^{2 \times 3}, x in R^{3} and b in R^{2}?  #102
• Changing error referencing "pardiso.lic" to "panua.lic" Check for consistency of Panua/Pardiso releated error messages etc. #106
• Store internal Vector{Int32} versions of colptr and rowval when using Panua in order to avoid memory usage in the case of the sparsity pattern not changing.

[mipals]

Tests fail on 1.6 as we compare the against results from SparseArrays which did not support Float32 and ComplexF32 on 1.6. We could either stop testing on 1.6 and move the new LTS of 1.10 or we could compare with an answer computed using Float64 and ComplexF64. What do you think @j-fu ?

[j-fu]

I think if we drop testing on 1.6 we also would have to bump the min julia version, most of the ecosystem including LinearSolve.jl is going to 1.10 anyway.
Just had a look, MKL.jl now requires 1.9. Which suggest that we would test on 1.6 with a quite old version of MKL.

OTOH this would be kind of a pity as there is no real reason to in the package code which would require a higher version of 1.6. But I think this is too much sentiment, and we should focus on keeping maintenance simple...

[KristofferC]

But I think this is too much sentiment, and we should focus on keeping maintenance simple...

Agree with this.

Regarding this PR, should there be a check that the iparam is set correctly similar to the checks in

Pardiso.jl/src/Pardiso.jl

Lines 326 to 329 in a645c66

	if Tv <: Complex && isreal(get_matrixtype(ps))
	throw(ErrorException(string("input matrix is complex while PardisoSolver ",
	"has a real matrix type set: $(get_matrixtype(ps))")))
	end

?

[mipals]

FWIW the package would still be compatible with older version - it would just be the MKLPardiso tests for Float32/ComplexF32 that would fail. But I agree that it would probably be best for the tests to still run on 1.6.

Because of this I've fixed the tests so that they should not fail on 1.6 by computing the reference solution in Float64/ComplexF64 and then converting the results back to Float32/ComplexF32. For some reason a few of the tests for Float32 inputs fail when using MKL_jll v. 2025 (locally the tests seem to run fine using e.g. 2023, 2024 but fail similar to the CI when using 2025).

[mipals]

The error was not in the MKL_jll version, but rather that the hermitian positive tests where quite ill-conditioned (I still don't understand why this was only caught on 1.6 - did something change with Random since then?).

The current solution is to add a diagonal to the hermitian positive tests. At the same time i've changed the tests so that they check that solution works rather than comparing with the answer from SparseArrays (in the failures yesterday both solutions were actually wrong but the tests failed only because they two solutions where not equal).