provide common physical constants to EKAT clients

[pbosler]

Motivation

A common set of physical constants is desirable; here's a first attempt at factoring such a thing out of scream and into ekat.

Closes #48

Once merged into EKAT client codes (haero/scream, e.g.,) could update their constants treatment to use the ekat values. Note that some unit conversions will be required; Scream tends to use SI units except for amount of substance, where it uses kilomoles instead of moles, for example. Not hard to do, just a note for future work.

Design choices

• All values are SI units (kg, m, s, mol, K, ...). Clients are responsible for converting from SI to a different unit, where necessary.
  • The main difference between SI units and E3SM is in molecular weights; E3SM uses g/mol frequently. Also, several gas constants and Avogadro's number are often per kmol in E3SM. Here they are all SI, kg and mol.
• The single source file is ekat/src/physics/constants.hpp. From that file, a CMake parser (thanks, @jeff-cohere ) auto-generates a .cpp and a .f90 file so that the values are defined in only one place. The tests include independent definitions of the constants.
  • This PR adds a .gitignore file to exclude these auto-generated source files from the repo --- they will be autogenerated whenever constants.hpp is updated.
• The CMake parser takes its cues from some hard-coded strings and requires that each constant be preceded by a line beginning with the flag ///
• All constants from e3sm/share/util/shr_const_mod.F90 are included except the "special values" that could be replaced with some form of nan moving forward

Testing

2 tests are added, one for c++ and one for fortran.

Additional Information

This PR will be the first in a series that pull "common physics" from Scream into EKAT. Constants are simple enough that they seemed a decent starting point.

[pbosler]

Closing to consider a more robust approach based on yaml, rather than CMake.

[bartgol]

FWIW, the physics/constants.hpp file seemed ok to me, and we could easily have two files instead of auto-generating one. Yes, more maintenance cost, but we can add tests to ensure they are the same, and I don't think it's a huge cost anyways. Probably easier than auto-generate code.

Perhaps, to avoid bad surprises hard to debug, we could add a static_assert in the class, verifying that Scalar is indeed a floating point type.