Draft: Add symmetry support through spglib

This MR adds support to SIESTA for symmetries through the use of the spglib library. We currently implement the automatic determination of the space group of the input structure and (optionally) the user can request to conserve the detected symmetries during structural relaxation. The branch has been synced with master and has extended the cmake build system to link with spglib. The core functionality (space group detection and symmetry conservation during relaxation) has been tested (also after the sync with master). There are some points that still have to be addressed and open questions for which I would like your input which I will list below.

TO DO

• Rename occurrences of syms in the code to symmetry as requested by Nick Papior in #71
• Rename relevant spglib modules to <name>_m.F90 format as requested by Nick Papior in #71
• Add section(s) in the user manual (documentation) about the symmetry support
• Move very verbose output of symmetry info into DEBUG preprocessor block or remove it
• Prettify symmetry output
• Add sections in NetCDF and/or XML file with symmetry info?
• Check if there is still an spglib tarball somewhere and remove if this is the case

Open questions First about the build system. I am fairly new to cmake so please have a look and see if there are any improvements that have to be made in how I search for and link with spglib. Moreover, currently I treat the spglib library as fully external. The user has to download, build and install it somewhere themselves and add the install directory to the CMAKE_PREFIX_PATH. It's handled similarly as the other (strongly) recommended dependencies (output for spglib is also listed in the same section as these libraries in the cmake output) and it follows the same logic that it's turned on by default if it's found. You can still toggle it's inclusion though with WITH_SPGLIB if you want. Is this okay? Or should we make it mandatory, include a git submodule and a way to compile it on the fly such as for xmlf90?

Then about the code itself, I had the following open questions:

• How should we shape the spglib tests? I saw that the tests have recently been reshaped to work better with the cmake build system. I suppose a similar thing has to happen for the spglib tests? Are there any guidelines/restrictions about how computationally demanding the tests are allowed to be?
• spglib is very finicky about the precision with which you give the initial coordinates of the system. According to Matthieu Verstraete the experience of the ABINIT project is that they needed at least 10 digits after the decimal point. Since this is currently not the case in any of the text output files (FA, XML, standard out) you might get a different symmetry (mostly different Wyckoff positions of atoms, space group is still the same) after a relaxation if you feed the output coordinates into a new simulation. If you use the coordinates from the NetCDF output (which have no loss of precision) then you do get the exact same symmetry as in the initial case. What should we do with this? Increase precision in text output files? Or advise users to use NetCDF output?
• Currently we are using our own internal fortran interface (spglib_f03.F90) in the code but current releases of spglib also include a fortran interface (spglib_f08.F90) in the include directory of the install dir. We could include this source files to the source files of libsiesta in the cmake build if spglib library is detected and remove our own interface. This might remove some maintenance burden. What do you think/prefer?
• Matthieu also implemented symmetrization routines for the input cell and input atomic positions. While the symmetrization of the positions is working well, the symmetrization of the cell is not. What makes the symmetrization of the cell difficult is that the symmetry operations are given in terms of the cell vectors (reduced coordinates), so if the cell vectors are off, the symmetry operations will be as well. spglib also provides a routine to symmetrize the input cell but that has as a downside that it sets the cell to adhere to some standards for crystal space groups which might drastically alter the input structure (also change number of atoms and stuff like that). What should we do about this? Use the spglib routine anyway but properly warn users about this. Try to find an algorithm that can symmetrize the input cell and keep it in the same form/orientation. Just not provide a symmetrization routine and just issue a warning that users have to make sure that input is properly symmetric?

Lastly, any feedback/comments/suggestions for improvements are more then welcome. In the future there will also follow an MR for using the symmetries to reduce the reciprocal space grid to the irreducible one, but there is still quite some work to be done on that. Also, see #71 for a further discussion about this.