Update bundled BLAS/LAPACK code

[ohearnk]

NOTE: do not merge this until the issues/limitations listed below are handled and the broader philosphical discussion is settled regarding how to be handle updates to QUICK dependencies (i.e., git submodules vs. internal inclusion directly into the QUICK repo).

This PR updates the bundled BLAS/LAPACK routines to the latest stable release for the reference LAPACK implementation (v3.12.1). Moreover, to enable easier inclusion of updated code for dependencies, a fork of the upstream reference LAPACK repo was created, and a git submodule was added to point to this fork. Updates to the Github CI workflows for testing are also included to reflect the addtion of submodules.

Speaking more broadly, this PR is meant as an intellectual exercise and as discussion fodder for investigating better approaches for maintaining and updating external code dependencies for QUICK. The current list of such dependencies in the QUICK codebase along with suggested upstreams is as follows:

• BLAS/LAPCK (src/blas and src/lapack): dense linear algebra CPU routines bundled as fallbacks (inherited from those bundled with Amber/AmberTools) -> reference LAPACK
• DFT-D3 (src/dftd3): DFT-D3 dispersion corrections -> simple DFT-D3
• XC (src/libxc): exchange-correlation functionals for DFT -> libxc
• DL-FIND (src/dlfind): geometry optimization -> libdlfind

Using git submodules for these dependencies would allow easier tracking and updating for fixes and feature additions from upstream. Moreover, to better track local modifications of these dependencies for interfacing with QUICK and to guard against upstream disappearing, forks of these upstreams could be created and managed independently under the organization account which QUICK is under (i.e., merzlab for now). This PR does so with the reference LAPACK upstream.

Limitations / Issues with this PR:

• The fork of the upstream reference LAPACK repo is under my personal account. If this approach is adopted, this fork should be moved to instead reside under merzlab or equivalent (I do not have permissions to create this).
• For tests under the Github CI workflows, the build system used for QUICK was matched for reference LAPACK (i.e., CMake, legacy configure/Makefile). For the legacy configure/Makefile system for reference LAPACK, there is not a build target for generating shared libaries. As such, this was added on top of the v3.12.1 tag in my fork (see the branch v3.12.1-with-quick-patches for further details).
• Additionally, again for the legacy configure/Makefile build system of reference LAPACK, a makefile template is required for builds (make.inc in the base directory of the repo). Examples templates are provided under INSTALL for various types of systems -- the GCC template is what I used and copied to the base directory in order to get the Github CI workflows to run (as GCC is the compiler currently used for testing). However, for releases, GCC cannot be assumed by end users who are using the bundled BLAS/LAPACK code. This needs to be addressed, possibly in conjunction with the compiler type selection in the build systems.
• There may be additional complexity in inclusion of QUICK with Amber/AmberTools, particularly if the QUICK git repo history is grafted onto the Amber/AmberTools repo. However, this could be mitigated by not including the submodules config or their history but instead just including the submodule contents. Regardless, this all would need to be ironed out (and the stance on git submodules clarified for Amber/AmberTools). Same would apply to any additional projects using QUICK in an embedded manner.