Upgrade MadNLPHSL.jl

[amontoison]

Require the new release of HSL_jll.jl and this PR of HSL.jl:
JuliaSmoothOptimizers/HSL.jl#215

@frapac You will be able to easily try it.

[sshin23]

This is great! @amontoison, does only ma27 support quad precision? I guess it might be tricky once they rely on BLAS

[amontoison]

Quadruple precision will only be supported in MA27 for the upcoming release of HSL_jll.jl.
However, the next release will bring other useful features, such as support of Int64 for the HSL solvers interfaced in MadNLP.

For supporting quadruple precision in other HSL linear solvers, we have a few challenges.
The first is the convention for BLAS/LAPACK symbols, which isn't standardized in quadruple precision:

• Convention for symbols in quadruple precision Reference-LAPACK/lapack#1072

Next, I need to add these symbols to LBT, as some of them are missing:

• Add new BLAS and LAPACK symbols in quadruple precision JuliaLinearAlgebra/libblastrampoline#145

Finally, we need a BLAS/LAPACK library compiled in quadruple precision with the relevant symbols.

@nimgould plans to port the subset of routines needed in quadruple precision:

• Revamped GALAHAD reference LAPACK/BLAS ralna/GALAHAD#337 💪

We might be able to include this in HSL_jll.jl, but all of this is speculative and will take some time before it becomes available.

[sshin23]

Looks good @amontoison! Now I think it is a good time to get rid of Int32 from MadNLP and make Int64 the default (but in a separate PR)

[amontoison]

MA27 can also be used with quadruple precision with the PR.

I tested with the future version of HSL_jll.jl 2025.x.x that support Float128 for all solvers and it works too.
I did the modifications in HSL.jl such that we don't need to update MadNLPHSL.jl again.

The function HSL.is_supported will automatically return true with Float128 for ma57, ma77, etc...

[amontoison]

@frapac Can I merge this PR?