[CMake] handle submodule codes in release tarball

Close #298 (closed)

Introduce external/submodule_commit_hash_records to record git submodule commit hashes which are stored previously only in the database under .git which is not included in a release tarball. Make CMake working when release tarballs are used.

In this MR when using cmake,

1. If QE source codes are git cloned, git submodule takes care of downloading external packages. git submodule actually clones the repo of external packages and checkout the reference commit whose hash is recorded in QE repo database. In addition, this case also do a consistency check ensuring the git dabatase hash is consistent with submodule_commit_hash_records regarding the external packages. So CI secures submodule_commit_hash_records
2. If QE source codes are unpacked from tarball, there is no QE repo git database. Our CMake clones external package repos based on URLs from ".gitmodules" and checks out recorded hash based on submodule_commit_hash_records file.

Overal currently internal stored archives are never used in the case of CMake.

A few advantages over storing archives or wget.

1. minimal QE repo size. Easy to update an external package.
2. use git to download external packages securely validated by recorded commit hash. It is immune to remote changes. Wget without validation is potentially a risk.

Disadvantage, need git (who doesn't have it) and internet access (same as wget). So a backup solution in case of no/slow internet will arrive in a later MR.

@giannozz I think the classic "configure" can also use the same mechanism (.gitmodules + submodule_commit_hash_records) and get rid of package archives.

Test this out by download release tarballs from https://gitlab.com/ye-luo/q-e/-/releases/cmake-experiment

@danielecesarini @pietrodelugas @ltalirz you may try this out