Improve VQ run-time parameter workflow and add constants to config

[markyoder]

summary of objecctives:

1. clean up the run-time parameter file workflow, eliminate redundancies. for example:
   a) if an output file is specified as "*.h5", assume hdf5 format.
   b) permit a generic "sim.greens.inputoutput" file that acts universally as an input/output based on the sim.greens.method = {file, standard, etc.} value.

the basic idea is to simplify the input logic tree to be more user friendly, still very flexible (aka, sim.file-output_event_type=text && sim.file.output_event=blah_blah.h5 will still write a text file, but sim.file.output_event=blah_blah.h5 by itself will default to hdf5).

2. add constants, scaling exponents, etc. (optionally) to the input parameter file. we can use the same, standard params.d file (regular run-time parameters), or we can use a separate text/hdf5 file (which might be a better idea, since we might want to move around these parameterizations differently). example parameters are: UpdateBlockStress.cpp:UpdateBlockStress::init():
   double rho = 5.515e3; // density of rock in kg m^-3
   double g = 9.81; // force of gravity in m s^-2
   double depth = 0.0;
   (though what we might do is add a depth_default=0.0 run-time parameter). there are also instances in rupture length, area, etc. calculations where constants and scaling exponents are specified.

what we'd like to see is a framework whereby, going forward, these values can be easily removed from hard-coding and added to the parameter file. supplying default values will, of course, be critical. maybe a SimParameters() class? or maybe just a simple map/dict object. presumably, we want a workflow like (for a case where we're assigning a variable that might be found in the parameters file):
double default_rho = 5.51e3;
double rho = sim->get_var("rho", default_rho);
where get_var will either retrieve the variable "rho" or assign the default_rho value.

3. can we (optionally?) integrate the fault model + greens_functions files? the motivation for this is simple: a set of greens_functions is compatible only with a very specific fault model. this may simply be a matter of combining the salient components from the greens_functions (greens_normal, greens_shear) and the fault_model hdf5 files into a single file and pointing both the 'greens input' and 'fault input' (not naming them correctly here), in the input parameters file, to that file. referencing syntax like "my_h5_file['my_table']['my_col'] will not be concerned about which other tables we've stuffed into the file.

[kwschultz]

See the next issue on setting constants in the parameter file.