sicor_ac.ac_gms() requires user specific options files which are created by running sicor_ac.ac_gms()

sicor_ac.ac_gms() requires the user to provide an options dict that already contains all the parameters from one of the user specific sicor_*_user_options.json files. However, if SICOR is installed from PyPI or conda-forge, these user specific files are not yet created because get_tables() needs to run first. But get_tables() is first called in sicor_ac.ac_gms(). This cannot work and causes the AC of GMS to fail.

I took a look at the user specific options files and the only difference I can see is that the hardcoded paths in there are different. But at the moment, I don´t understand why the filename (aka '*_fn') keys contain hardcoded paths at all. Wouldn´t it be sufficient to provide generally usable options files in the repository that only contain the filenames of the tables without any hardcoded paths? Alternatively, to make the options file clearer, you could also include relative paths in there (relative to the sicor main directory - which is always the same on any machine).

I think the intention of the absolute paths in the options files was that the user can manually run get_tables and save the tables separately from sicor (and not within the Python site-packages directory). In this case, SICOR must know where the tables are. But why not just adding a key to the options files that specifies the default tables directory (as a relative path), which can be overridden by the user if desired? This way, the user can use the general options.json files provided in the repo. ac_gms then only has to check if the user really did provide a custom options directory or not. If yes and the files are not there, raise an exception. If no and the files are not there, run get_tables and download them.

What do you think?