Introducing ``ParameterMap``

[mabruzzo]

Adds a new ParameterMap class to assist with parameter parsing.

Motivation

Currently, Cholla works by storing runtime parameters within a global Parameters struct/class and then the instance of the Parameters struct gets passed around to various parts of the code, which read needed values from the struct. While there is nothing wrong with our current system (it definitely gets the job done!), there are a couple of drawbacks.

For example:

• to add a new parameter, you need to introduce a new parameter to the Parameters struct and you need to add parsing code to global.cpp. This can be somewhat undesirable since the list of parameters may be quite separated from the logic that needs it.
• it introduces a bunch of ifdef-statements within the Parameters struct in the cases where a parameter is only used in certain configurations. (this logic is needed to check for unused parameters)

Athena++ (and more recently, Enzo-E) adopt a cool solution where they initialize an instance of a class that stores all the arbitrary collection of specified parameters and their values (Athena++ calls it ParameterInput).

• Unlike, our Parameters struct this object doesn't have any expectations about what the expected parameters are or should be.
• They then pass around this object to the various "code-modules" and have the modules access the parameters they need through this object.
• Introducing a new parameter to a given "code-module" is as simple as having that code-module check for the name of that new parameter. Consequently:
  • the names of parameters needed by a given module are located in a similar code-location
  • if you use disable a given module with an ifdef statement, you are also disabling the parsing of the parameters needed by that module.

This PR doesn't try to do all of that. Instead, we essentially take the first step towards that system. We introduce a class like ParameterInput.

Overview

This class introduces the ParameterMap class. This class is used to store the contents of a parameter file like a "map" (or a python dictionary). It provide methods to access the values associated with a given parameter along with the expected type. It also has the ability to specify a default value.

In the future, the idea would be to pass around an instance of this map to configure various "submodules". For example, it would be easy to do this to specify runtime args for the feedback module introduced by PR #386 or the galaxy ICs in #387 or configuring the grackle module.

[mabruzzo]

From the failing tests, I assume I made a logical error somewhere. My best guess is that it's related to reading in options passed on the command line? (if so that could have happened during the rebase)

I need to fix that issue. But otherwise, I think people can still review this PR (I don't think anything will change much)