[newchem-cpp] ratequery rate-fetching-recipes now report the array shapes of fetched recipes

[mabruzzo]

To be reviewed after #594 is merged

---

This PR modifies the ratequery machinery so that recipes for accessing the rates now directly report the shape of each rate.

Motivation

Some basic background:

• the vast majority of rates (or entries) that are queryable through the ratequery machinery are made accessible through a callback function (called a "recipe") that fetches the basic entry information.
• prior to this commit, all entries accessed through a "recipe" had to share a common shape and the recipe itself didn't actually specify the shape of the returned buffer (i.e. the shape of all buffers accessed through a recipe were specified alongside the recipe when registering the recipe)

This PR changes things so that the recipes directly specify the shape of the fetched rate. This is important for making it easier to create recipes for the cloudy interpolation table. When you think about the axes of the cloud interpolation table (e.g. the $T$ array, the $n_H$ array, the $z$ array), they all have different shapes. Thus the old system would have required separate recipes for each of those axes. The new system makes it possible to create a single recipe for all of the axes. This will also be important if we want to make other kinds of multidimensional interpolation tables queryable in the future (plus, it slightly simplifies ratequery::EntrySet).

Note: this PR does NOT actually make the cloudy interpolation table accessible through the ratequery machinery (I have a separate mostly finished PR for doing that)

The changes

The specific changes in this PR include

• renaming ratequery::{EntryProps->EntryShape}
• making ratequery::EntryShape more class-like
  • the existing EntryShape_is_valid function is now a method
  • the This PR modifies the ratequery machinery so that recipes for accessing the rates now directly report the shape of each rate.

Motivation

Some basic background:

• the vast majority of rates (or entries) that are queryable through the ratequery machinery are made accessible through a callback function (called a "recipe") that fetches the basic entry information.
• prior to this commit, all entries accessed through a "recipe" had to share a common shape and the recipe itself didn't actually specify the shape of the returned buffer (i.e. the shape of all buffers accessed through a recipe were specified alongside the recipe when registering the recipe)

This PR changes things so that the recipes directly specify the shape of the fetched rate. This is important for making it easier to create recipes for the cloudy interpolation table. When you think about the axes of the cloud interpolation table (e.g. the $T$ array, the $n_H$ array, the $z$ array), they all have different shapes. Thus the old system would have required separate recipes for each of those axes. The new system makes it possible to create a single recipe for all of the axes. This will also be important if we want to make other kinds of multidimensional interpolation tables queryable in the future (plus, it slightly simplifies ratequery::EntrySet and ratequery::RegBuilder).

Note: this PR does NOT actually make the cloudy interpolation table accessible through the ratequery machinery (I have a separate mostly finished PR for doing that)

The changes

The specific changes in this PR include

• renaming ratequery::{EntryProps->EntryShape}
• making ratequery::EntryShape more class-like
  • the existing ratequery::EntryShape_is_valid function is now a method
  • the ratequery::mk_invalid_EntryShape is now a factory method
  • I added other factory methods to ratequery::EntryShape and made the default constructor private in order to force people to use the factory methods
  • For some context: since all of the recipe functions now need to specify the ratequery::EntryShape I felt it was important that all code for specifying the shape had to be very explicit (and I wanted to make it very harder to make a mistake when specifying shape)
• I adjusted ratequery::EntrySet and ratequery::RegBuilder to reflect the fact that recipe functions now included the entry shape (the implementation of these classes definitely got simpler)
• I stored a copy of the NumberOfTemperatureBins input parameter inside of gr_opaque_storage.
  • Honestly, this is a bit of a hack. But, it was the most convenient way to make the shape of all of the 1D rate arrays accessible through recipe functions.
  • For context, the ratequery machinery was all designed to function without being passed a pointer to the chemistry_data struct. We can revisit this in the future if we want
• I updated each of the existing recipes to now report the shapes of the associated recipes

Followup

A followup PR will make the cloudy interpolation tables accessible through the ratequery machinery. (At the time of writing, that's 95% done)