Modularize BLAS and LAPACK modules in CMake to make it easier to use in external projects

[eduardz1]

This PR is the start of #1031, it currently only separates the BLAS and LAPACK. This means that, when including the stdlib in a CMake project through FetchContent, we can link only the fortran_stdlib::blas or fortran_stdlib::lapack targets. This kind of approach might become a bit difficult to manage in the future so there should be some careful discussion about which library could be exported as separate targets. I have started with BLAS and LAPACK because writing interfaces for the two is something that happens way too often. I have also created aliased targets with the namespace to make it a bit nicer to work with when included.

[perazz]

Thank you for this PR @eduardz1. In the interest of maintainability, I think it would be preferable to keep the file lists for blas and lapack targets in their respective blas/ and lapack/ subfolders, rather than moving everything into the top-level CMakeLists.txt.

I would suggest to move the BLAS/LAPACK file lists and target setup code back into their blas/ and lapack/ subfolders.
Keep the top-level src/CMakeLists.txt streamlined.
Then, use add_subdirectory(blas) and add_subdirectory(lapack) from the top-level.

[eduardz1]

Thank you for this PR @eduardz1. In the interest of maintainability, I think it would be preferable to keep the file lists for blas and lapack targets in their respective blas/ and lapack/ subfolders, rather than moving everything into the top-level CMakeLists.txt.

I would suggest to move the BLAS/LAPACK file lists and target setup code back into their blas/ and lapack/ subfolders. Keep the top-level src/CMakeLists.txt streamlined. Then, use add_subdirectory(blas) and add_subdirectory(lapack) from the top-level.

I had to slightly change the preprocess function to make it work again with subfolders

[eduardz1]

A solution could also be to have a stdlib_commons target or similar, but I am not familiar enough with the codebase to judge what would be best suited for it (surely stdlib_kinds, probably stdlib_error, but the others I am less confident). At the moment the common modules are compiled once for the common target, once for the LAPACK one and once for the BLAS one. I don't think this is too bad, as it allows us to worry less about having a perfect dependency graph

[perazz]

LGTM, thank you @eduardz1 for this improvement.

[eduardz1]

Thanks!