Athena NumPy Fix, master branch (2020.05.05.)

This is to fix the issue described in ATLINFR-3417. As described in the ticket, numpy in LCG_97 is linked against LCG's lapack library.

The thing is, we actually do use LAPACK in our code directly.

• https://gitlab.cern.ch/atlas/athena/-/blob/master/Reconstruction/VKalVrt/VrtSecInclusive/CMakeLists.txt
• https://gitlab.cern.ch/atlas/athena/-/blob/master/Tracking/TrkAlignment/TrkAlgebraUtils/CMakeLists.txt

But these do not set up LCG's lapack installation. 😕 They instead make use of LCG's (open)blas installation. As it provides the API for both BLAS and LAPACK... And apparently CMake's FindLAPACK.cmake module prefers that implementation. 😕

...
-- Configuring the build of package: VrtSecInclusive
-- Looking for Fortran sgemm
-- Looking for Fortran sgemm - not found
-- Looking for Fortran sgemm
-- Looking for Fortran sgemm - found
-- Found BLAS: /cvmfs/sft.cern.ch/lcg/releases/LCG_97/blas/0.3.5.openblas/x86_64-centos7-gcc8-opt/lib64/libopenblas.so  
-- Looking for Fortran cheev
-- Looking for Fortran cheev - found
-- A library with LAPACK API found.
...

After some pondering, I decided to just hardcode in the Athena project configuration that we need to add the lapack package's library directory to LD_LIBRARY_PATH. To which this seemed the most practical implementation...