lib/gmath: properly guard BLAS and LAPACK dependent code

[nilason]

Properly guard BLAS and LAPACK dependent code.

[nilason]

I used Mac runner to test without --with-blas and --with-lapack and it succeeded. Opening for review.

[neteler]

Side-question concerning addons:

In my fork I get
https://github.com/neteler/grass-addons/actions/runs/10937266666/job/30362726188

checking for lapacke.h... no configure: error: *** Unable to find "lapacke.h" with "-I/usr/include/x86_64-linux-gnu/openblas-pthread/ -g -O2 ". Error: Process completed with exit code 1.

Would that be addressed here as well?

[nilason]

OSGeo/grass-addons#1206 adds liblapacke-dev which is enough.

[nilason]

I have now updated this to work as it did before d5bb442. Namely, to only compile lib/gmath/la.c (and being able to include la.h) IFF compiled with BLAS and LAPACK.

The first solution (02b0d96) made available all parts which weren't directly using BLAS or LAPACK (only a couple of functions out of 30+) even without compiling with BLAS and LAPACK.

I'd say we follow the original logic and go for the present state of this PR. If need arises in the future, we may revise this.

[wenzeslaus]

Sounds like a straightforward solution.