[Param Update 2 of 2] Eager Parameter Parsing

[mabruzzo]

This should not be reviewed until after #503 is merged (if it's merged at all)

---

This PR updates the internals of ParameterMap to eagerly parse in parameter values while reading in a Parameter File. This sort of eager parsing is only possible now that #503 has been merged.

Additional Context

Prior to #503 the intended types of the values in the following snippet were ambiguous:

key_bool=true
key_integer=1
key_float=1.0

To be a little more specific, true could be a boolean or string, 1 could be an integer or string, and 1.0 could be a float or a string. Because of this ambiguity, ParameterMap had to be very lazy about converting values from the original strings. In other words, ParameterMap would have stored std::string instances holding "true", "1", and "1.0". It only tried to parse the value when when the parameter was actually accessed.

The change in PR #503 removed this ambiguity since strings must now be quoted (in other words, none of the values in the snippet can be string values under the new rules). For minimized the size of the proposed changes, PR #503 remained quite lazy about when the parameter values are parsed.

This PR proposes changes where the values of parameter files are immediately parsed. They are stored in a new type called param_details::Value, which is a safe union that directly holds either a bool, int64_t, double, or std::string.

Why make this change

There are several lines of motivation for making this change:

1. Cholla can now immediately reject a lot more parameter files that are written with invalid syntax (under the old-system we could only reject ill-formed values if we actually tried to read it through its associated key). I think this is actually a really big deal.

2. This change makes it possible to go back and revisit PR WIP: Dumping hdf5 parameters #409. As a reminder, that PR records parameters inside an hdf5 file. In my mind it makes a lot more sense to record values after they have been converted to bool/double/int/properly escaped strings than to store the original raw strings from the parameter file (the raw-string plan would require you to use a toml library to actually use the dumped parameters)

3. This is an essential step to using an external toml-parsing library (e.g. it should be straight-forward to replace our param_details::Value class with toml::value from toml++)

4. Finally, this is a pretty crucial step to introducing alternative command line argument syntax to more easily override string parameters

   • the idea here is to make it possible to write outdir:str=blah where :str would make it clear that blah is a string
   • to be honest, this was actually my initial motivation for making this PR.
   • In fact I got very far with making the change (it's quite simple to add to this PR). But I decided to scrap it for now. I want to get a sense whether other people actually specify parameters on the command line (if I'm the only person, I'm personally content to manually escape my quotes).

---

Just like #503, this will fail tests until we convert all the parameter files for the system tests using the script provided with #503.