CMake: add install target

[skosukhin]

1. Add the install target. Installs the rte and rrtmgp libraries together with their module files.
   TODO: consider fetching and installing the rrtmgp-gas-*.nc data files from rrtmgp-data as there are users who consider them to be part of the library.
2. Generate and install CMake config, target and version files to enable find_package(rte-rrtmgp) in the user projects. The COMPATIBILITY is set to SameMinorVersion, which means that if the users need version 1.8, any 1.8.x version suffices but neither 1.7.x nor 1.9.x do.
3. Export the targets to the build directory to make the project locatable from the build directory as well (i.e. find_package(rte-rrtmgp) with CMAKE_PREFIX_PATH containing /path/to/rte-rrtmgp/build). This part also required some tweaks for the rtekernels and rrtmgpkernels object libraries since we don't want to expose them to the users (at least for now).
4. Add public aliases in the rte-rrtmgp:: namespace so the project is fetchable and addable (with add_subdirectory) by the users' application projects.

[RobertPincus]

@skosukhin
Re 1, it might indeed make sense to fetch the data during installation, especially if there are ways to override the location/update the data (do we add CMake to the data repo?)
Re 3, there may be times that users need access to front-end and kernel-libraries separately, e.g. when using the C++ front end with the Fortran kernels.

[RobertPincus]

Thanks again, @skosukhin. Note that we may want to kernel libraries to be visible e.g. when using the C++ front end with the kernel libraries.

[skosukhin]

Re 1, it might indeed make sense to fetch the data during installation, especially if there are ways to override the location/update the data (do we add CMake to the data repo?)

What is the full list of data files that you think should be installed?

Re 3, there may be times that users need access to front-end and kernel-libraries separately, e.g. when using the C++ front end with the Fortran kernels.

Currently, the kernel libraries are only auxiliary OBJECT libraries. They are not produced by the build system (i.e. there are no respective *.a files) and their objects are simply injected into librte.a and librrtmgp.a. I will need a better understanding of the source code structure to come up with a suggestion on what build artefacts we should produce and install. At the moment, this is similar (as much as it makes sense) to how things are done in the autoconf branch.