[newchem-cpp] Remove Hard-coded injection path names from grackle_field_data

[mabruzzo]

To be reviewed after #479 is merged

---

This PR replaces all hard-coded injection pathway data-members from the grackle_field_data (e.g. grackle_field_data::local_ISM_metal_density, grackle_field_data::y19_metal_density, ...) with an array of pointers known as grackle_field_data::inject_pathway_metal_density. In other words, Grackle no longer hardcodes the names of each injection pathway members as part of the grackle_field_data struct. (To determine the names, users must use the query-machinery introduced in #479).

This is significant for 2 reasons:

1. I think the old approach would have been a pretty bad choice from an API perspective
   • injection pathway models or supernova models is the exact sort of thing where one might expect "churn"
   • under the old approach, we would have needed to keep adding more and more members to grackle_field_data whenever someone wanted another model (while maintaining members for all existing models)
   • Likewise, a simulation code that wanted to use another model would need to add several lines of code to support each kind of model
   • the newer approach is much more scalable
2. It's also important from an implementation perspective:
   • the number of inject field paths are now entirely determined by the values read in from the table. To add/remove/rename pathways, you "just" need to modify inject_model/raw_data.[ch]pp and inject_model/load_data.[ch]pp.
   • this is a massive step that will make it possible to move this data into HDF5 tables (and let users supply arbitrary data)

[brittonsmith]

This is great. I'm excited to start using it. It also finally hit me what has been rubbing me the wrong way about the injection pathway metal densities. For all but the first one, the name refers to a progenitor supernova making the metal. However, "local_ISM", while also alluding to an abundance pattern, is doing so through a different conceptual path. This is a single field representing an abundance pattern. I'm not at all advocating for a change in the naming convention but I think this will be crucial in the documentation.