Feature/improvement requests for the upstream KROME library

[sloede]

The intent is to collect all issues (small and large) that we currently have to work around in KROME.jl, which could possibly be fixed by changes to the upstream KROME library. This list is roughly ordered by priority (highest/most urgent first).

• Add make target to build shared library and C interface (Use new make target csharedlib and csharedlib_opt #11)
  Right now, we use a dirty hack in deps/build.jl to build both the shared library (required for use from Julia) and the C interface (required to use CBindingsGen for auto-generating the C interface functions). We should ask the KROME devs to add a build option (i.e., a new Make target) that does both things, maybe something like make cshared. Of course it would be then nice to also have an optimized version, i.e., make cshared_opt.
• Allow overriding the path for reactions_verbatim.dat (Override verbatim reactions file path #12)
  Currently, the path to the file reactions_verbatim.dat is hardcoded to the current working directory. This is particularly annoying when using KROME.jl, as it requires to always manually copy the file from a central location to where you are running Julia at the moment (which is facilitated with the install_reactions_verbatim() function at the moment. It would be nice if this path could be specified in the call to krome_init, or, to avoid API changes, by adding a new function krome_set_reactions_verbatim_path that can be called to override the default path before calling krome_init.
• Enable changing the C and Fortran compilers in the Makefile
  Right now, the use of gfortran and gcc is hardcoded for when building the Python or C interfaces. This requires some workarounds when doing CI testing with GitHub Actions on macOS (see .github/workflows/ci.yml, since by default gfortran is not available there (only the qualified gfortran-10), while gcc is actually an alias to clang (and you need to invoke gcc-10 to get the actual GCC compiler). It would thus be great if you could separately specify the Fortran and C compilers in the preprocessor script.
• Allow safely calling krome_init multiple times
  It would nicely integrate with the Julia workflow if it were possible to call krome_init multiple times without adverse effects. Maybe this is even possible now, but it does not seem documented in the upstream KROME library. We can also put the call to krome_init in the __init__ method such that it is performed automatically when using KROME, but this would still not prevent users from calling it manually.