Hotfix for asan build with flang

[daineAMD]

SWDEV-407304

Basically we shouldn't have a module split between two .f90 files. Disclaimer: I'm in no way a fortran expert.

Changes:

• add gfortran dep to clients for lapack when built with flang
• rename hipblas_fortran.f90 -> hipblas_fortran_blas.f90. Contains BLAS functions (for clients), doesn't have hipblas_interface module anymore
• remove hipblas_interface module from hipblas_fortran_solver.f90
• create hipblas_fortran_no_solver_module.f90 which includes hipblas_fortran_blas.f90 and has hipblas_interface module. Only built with --nosolver. This could be dealt with a preprocessor macro in hipblas_fortran_module.f90 instead but not exactly sure on best practices/compiler support.
• create hipblas_fortran_module.f90 which includes hipblas_fortran_blas.f90, hipblas_fortran_solver.f90 and has hipblas_interface module.

We should actually add support for different fortran compilers, this is just ad-hoc and seems to work, but not sure of the future of fortran here.

[TorreZuk]

LGTM to separate the overlap this way.
So flang will be used by them but we'll linking gfortran is okay? Did someone change our build to use flang? CI is failing for other reasons so can't see.

[daineAMD]

I tested locally by changing the compiler to flang and it seemed to work. The linking is just needed for the reference library, not really sure.
I'm not clear on how they're building hipBLAS in the ticket, they have their own bash script I guess. I'll wait to see if it fixes their problem using their build system (as well as CI with gfortran) before merging this.

[cgmb]

I've prepared updates that fix flang in the build infrastructure. That problem was in their configuration, not in the hipBLAS cmake code, so I recommend against adding workarounds here. (i.e., "add gfortran dep to clients for lapack when built with flang" is unnecessary.) However, the splitting of the interface to fix the no_solver build is still worth doing.