[newchem-cpp] Improve API-Test Harness (1/2): Chemistry Parameters

[mabruzzo]

To be reviewed after #468 has been merged

---

This PR is dedicated to improving the test Harness for using Googletest to execute API functions.

This PR specifically modifies the way that we work with the grtest::GrackleCtxPack type.

Background Context

The grtest::GrackleCtxPack type was introduced in a prior PR. It is VERY similar to gracklepy’s chemistry_data python extension type in that it tracks instances of Grackle’s chemistry_data and chemistry_data_storage types. It also tracks the initial ‘code_unitsstruct used to initializechemistry_data_storage`.

This type essentially serves 2 purposes:

1. provide a mechanism for properly cleaning up from a failed test (i.e. GoogleTest works best when destructors are used for that purpose)
2. Provide a convenient abstraction to easily setup a Grackle configuration (e.g. with standardized named presets) and keep track of that configuration

Description

This PR changes a few related things.

1. Track string allocations of chemistry-solver parameters as part of grtest::GrackleCtxPack
   • Prior to this PR, string parameters (namely grackle_data_file) in the chemistry_data instance wrapped by grtest::GrackleCtxPack essentially had to hold a string literal (the alternative was quite clunky)
   • This change makes it possible for the chemistry_data instance wrapped by grtest::GrackleCtxPackto hold arbitrary strings (very useful for testing purposes!)
2. Introduce the grtest::ParamVal type:
   • The grtest::ParamVal is type-safe wrapper around a union that can hold any kind of parameter value used by Grackle (i.e. a string, a nullptr, an int, a double)
   • This makes it possible to represent Grackle configurations as a list of key-value pairs or a mapping (in either case, the key is a string holding the name of a parameter and the value is a grtest::ParamVal instance)
   • The benefits of this, become more evident in the next item
3. Refactor the config-preset machinery so that it's implemented in terms of grtest::ParamVal
   • Prior to this PR, the chemistry presets directly mutated members of chemistry_data. Now, they specify a vector of name-grtest::ParamVal pairs that are subsequently used to initialize chemistry_data. This makes it easy to override/modify options
   • This vastly improves the ergonomics of initializing an arbitrary configuration. You have 3 choices:
     1. Use a named chemistry-preset (historically, this was the only option)
     2. Use a named chemistry-preset & selectively override parameters with key-value pairs
     3. Directly specify the desired parameters with key-value pairs
   • A fair amount of effort was invested to ensure that we could print this information in an easily digestible manner (for when tests fail!)
4. I updated the way error-handling works to make use of a new grtest::Status type
   • this is a common idiom for error-handling without exceptions. This comes up a lot in languages like Rust, and more recent C++ versions more direct support for this kind of thing
   • Basically, you can think of this as a "fat" status code (rather than just being an integer, it can contain detailed error message).
   • We introduce this type because Googletest wasn't designed to run with exceptions, and this type can be used to gracefully provide detailed error-message (compatible with Googletest's assertions) when things unexpectedly go wrong
   • This actually simplifies a lot of things, and will make it much easier to implement a few tests in the near future where we confirm that Grackle behaves correctly when we intentionally misconfigure it (in a few important ways).

Overall, this make the writing of api-tests with the googletest framework much more convenient. Things are still a little clunky, but I want to hold off on more refactoring until after we have written some tests

Payoff

The payoff of the changes in this PR are probably not immediately obvious. But they will become more obvious in some followup PRs that I will link here that will introduce some new tests to the Googletest framework.

I also have some ambitious ideas to reuse this machinery:

• as a benchmarking harness. Setting that up with this machinery will be straight-forward ( the bigger challenge there is coming up with input physical conditions that are indicative of real-world conditions)
• creating a command-line tool that can load and run a grackle configuration from an arbitrary input file (probably json or toml). This would be very useful when debugging weird behavior