Add accelerate backend with newer lapack from netlib

[isuruf]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[h-vetinari]

If I understand correctly, you're replacing the accelerate LAPACK with the netlib one, but leaving accelerate to provide the BLAS implementation, passed through the shim layer of https://github.com/mcg1969/vecLibFort, right?

Thanks for reminding me elsewhere that the ancient accelerate LAPACK version is the biggest issue with this, so from that POV, this plan makes sense. Netlib LAPACK will be quite slow though - any reason we shouldn't couple it with openblas (I guess the same question would go for blis)?

[isuruf]

Netlib LAPACK will be quite slow though - any reason we shouldn't couple it with openblas (I guess the same question would go for blis)?

No, it's not. Netlib LAPACK's performance depends on the underlying BLAS performance. OpenBLAS's LAPACK is basically Netlib's LAPACK with only a dozen functions that are optimized. (We use Accelerate's version for those dozen functions)

[h-vetinari]

Makes sense, thanks. Wasn't aware that LAPACK apparently just pieces together BLAS functions, I had thought that there were (more) separate functions...