Fix conda package build

[RaulPPelaez]

Some changes in the conda build infrastructure must have broken the conda build scripts. I noticed some incorrect things here and there that were probably the cause of it.
I also made it so that the conda package is built with a generic blas implementation, instead of relying on MKL. By doing it this way the resulting conda package is compatible with any BLAS, including MKL.

[github-actions]

✅ Linter reported no issues

All Python files are correctly formatted with Black.

[github-actions]

✅ Linter reported no issues

All C/C++ files are correctly formatted with clang-format.

[RaulPPelaez]

@rykerfish please review and merge. Wait until the last CI ends just in case it fails.
I will manually trigger the conda upload CI once this is merge (0.9.0 has not made it to anaconda yet due to the issues fixed here)

[RaulPPelaez]

The error comes from find_package(blas) linking against libopenblas instead of the generic symlink called just "libblas.so". When testing I am installing libblas from mkl to test that it is compatible and it fails.
Not sure what the best way to tackle this is. UAMMDSetup.cmake links agains BLAS::BLAS instead of just blas, which is probably tbe culprit here.

[RaulPPelaez]

This will probably work, but the resulting package will be compatible only with openblas. The key is in the finc_package(BLAS) and lapack most probably, somehow instructing it to find libblas.so instead of libopenblas.so

[rykerfish]

Whoops, hadn't seen your original comment before my next commit! I'll do a bit more research to see how we can make it link to something generic instead of openblas specifically

[rykerfish]

@RaulPPelaez I'm pretty surprised that last one failed. In the logs, I can see it finds the correct library

2025-07-02T21:13:54.7951452Z -- Found BLAS: $PREFIX/lib/libblas.so
2025-07-02T21:13:54.7953077Z -- Found LAPACK: $PREFIX/lib/liblapack.so;$PREFIX/lib/libblas.so

but it still fails. Could this be coming in on the solver-level CMake files? Each one calls uammd_setup_target and I'm a little suspicious of either these lines (although I think BLA_VENDOR should already be set and it should find Generic again) or maybe these lines? Alternatively, do we need to add libblas to runtime dependencies? The only thing that makes me think that is some of the warnings in the github runner logs, so I suspect we should look into other things first.

[RaulPPelaez]

Holly molly, FINALLY. TBH, I cannot explain exactly what the culprit was. Blas has a lot of idiosynchratic behaviors in conda-forge.

[RaulPPelaez]

Please review again @rykerfish

[rykerfish]

Looks good to me! I suspect part of our earlier problem was missing the correct BLAS libraries on the host side but that was hidden under the layer of us linking to the wrong BLAS binary. Nice fix!