Unify all Single Empiric Helmoltz models under one struct

[longemen3000]

At the moment, we have IAPWS95, PropaneRef, Thol's LJ (LJRef), and now Ammonia 2023. of course, all those models are specific instances of a Multiparameter single fluid. this PR:

• uses the new EoSModel, EmpiricSingleFluid, instead of each respective struct
• replaces IAPWS95, PropaneRef, the unscaled part of LJRef (from now onwards TholLJ), and the upcoming Ammonia2023
• adds a parser for JSON files in CoolProp format, that generates EmpiricSingleFluid models. the parser can be called via SingleFluid(component::String; userlocations =String[])
  Parsing all the current files in CoolProp, those are the available terms format:

Ideal models:

• IdealGasHelmholtzLead done
• IdealGasHelmholtzLogTau done
• IdealGasHelmholtzPlanckEinstein done, it is transformed to generalized einstein
• IdealGasHelmholtzEnthalpyEntropyOffset done, same as Lead
• IdealGasHelmholtzPower done
• IdealGasHelmholtzPlanckEinsteinGeneralized done
• IdealGasHelmholtzCP0PolyT done, transformed to a combination of lead, logtau and power terms
• IdealGasHelmholtzCP0AlyLee #not done, only n-Heptane and D6 have it, only 5 terms
• IdealGasHelmholtzCP0Constant done, transformed to a combination of lead and logtau terms

residual models:

• ResidualHelmholtzPower done
• ResidualHelmholtzGaussian done
• ResidualHelmholtzGaoB done
• ResidualHelmholtzNonAnalytic done, only water have it, maybe optimize the heck out of it?
• ResidualHelmholtzExponential done
• ResidualHelmholtzAssociating done
• ResidualHelmholtzLemmon2005 not done, only R125 have it.

the ancilliaries are handled by our CompositeModel infraestructure, so if models are missing, it is just a matter of adding those. at the moment we only use the saturation pressure, vapour density and liquid density ancilliaries.

Ideal models are of the type IdealEmpiricSingleFluid . they are generated from the fields of EmpiricSingleFluid with no cost.

Another thing is bothering me is the coolprop files, i don't know if do we want (or can) ship those or get those from a predetermined location. ideally, i would like to use something an already existent instalation of CoolProp and get Clapeyron to automatically recognize said location. we can use our current database shortcut format to store:

Clapeyron.SHORT_PATHS["COOLPROP"] = "path/to/files"
SingleFluid("water",userlocations = ["@COOLPROP/water.json"])

solves #110, #111

[longemen3000]

@ianhbell , about the coolprop files, what do you recommend?

[ianhbell]

@ianhbell , about the coolprop files, what do you recommend?

I would recommend that you import CoolProp via Python, and then get the JSON data for a fluid from the Python interface. There is also this Julia package: https://github.com/CoolProp/CoolProp.jl but I don't think it is feature complete to expose the necessary function (get_fluid_param_string)

[longemen3000]

There is also this Julia package: https://github.com/CoolProp/CoolProp.jl but I don't think it is feature complete to expose the necessary function (get_fluid_param_string)

The julia library uses the shared library, so some direct access can be done:

using CoolProp #load CoolProp.jl
using Base.Libc.Libdl #dynamic linker std
handle = Libdl.dlopen("libcoolprop") #pointer to lib
dlsym(handle,:get_fluid_param_string) #pointer to method (exists)

edit: the function get_fluid_param_string already exists on the package, but it is buggy. fixing it