Modularization of liquid fuel properties in spray

[d-montgomery]

This PR is the beginning framework for generalizing the Spray module to work with different liquid property models (i.e. the existing model from PeleMP or a group contribution method). I have tested the changes using the SingleDropEvap case in PeleLMeX and created a draft PR for further testing. This is still a work in progress but I wanted to push the initial framework through now to avoid one giant PR later.

Major changes:

1. Liquid properties and associated functions are stored in a struct that is selected based on a compile flag SPRAY_GCM. This struct (and soon others) are located in SprayProperties.H
2. Moved the getInpCoef and getInpVal functions to SprayProperties.H as these will change based on the selected method.

Minor changes

1. Mixture density (rho_part) is now a function. There are two versions of this function in order to be consistent with the existing PeleMP model.
2. Renamed/removed some variables and added others for readability. Most notable is a new variable called diff_liqLatent_gasEnth, which replaces the old version of latent which wasn't really latent heat and was quite confusing at first.

Eventually all properties will be called as a function of temperature and users will have the option of using the GCM model from FuelLib. The necessary parameters will be read in at run time via an input file exported from FuelLib for Pele according to the updates in this branch of FuelLib.

[d-montgomery]

The SprayTest in LMeX is catching some small differences that I wasn't seeing in the SingleDropEvap case. The issue begins after I merged the development branch into this branch in #c5a41ea. The SprayTest passes for commit #22d8cd3 of this branch which was up to date with PelePhysics #598.

I checked out some of the recent commits from PelePhysics and this appears to be related to PR #595 (commit 037c048).

[baperry2]

I think the overall structure is good and we can probably merge almost as is, then make some refinements/port more properties to this struct.

Before merging, we should think about the nomenclature for the functions for both individual component properties and mixture properties. I think we can make these a bit more clear. For individual components, I parse _Li as the surname rather than liquid, component i. For the mixture, I think _part is short for particle, but in principle this could be used to predict liquid properties other than for spray particles.

Perhaps we can just omit the L from e.g. rho_Li, as this is the liqprops struct so it should be clear that these are liquid properties. And then for mixture properties either just have no suffix/subscript, or use _mix instead of _part. In EOS for gas phase properties, we mostly use i to denote species properties and no subscript for mixture properties (e.g. TY2E and TY2Ei are mixture and component properties, respectively). But we're not quite consistent with that convention and perhaps it's a bit confusing anyway. I'm open to ideas on what would be the most intuitive.