Mim should validate its inputs

[axch]

MIM should check each of the invariants that it expects about its inputs, and emit a friendly error message if they are violated. The general principle is, don't allow the user to wait a day for the simulation to complete before discovering that they made a mistake in the configuration, if that mistake can be detected ahead of time. For this software, I think it's better to be very pedantic about being very sure the inputs correspond to the user's intentions, because that iteration loop is so much faster than configure-run-plot.

The invariants I am aware of now are:

• [ ] ah, hmean, and g_vec are given as many values as there are layers (Fortran namelist input even has value repetition syntax)
• [ ] The input fields are the size given by nx and ny (Fortran read already crashes if they are too small, and we may not actually be able to fix the error message; but it would be nice to also complain if they are too big)
• [ ] The input wind magnitude time series, if present, is long enough to cover the whole simulation (it being too long is probably not a problem, because then just the prefix will be used)
• [x] Bathymetry file and initial layer thicknesses should be consistent (Issue #14)

[axch]

The shape of the solution to this depends somewhat on the packaging we want. In the current packaging, it makes sense for the MIM core to check these things. However, if we move to a more Python-wrapped packaging, we can write the input validation in Python, and let the core just trust that its inputs will be well-formed (and validate that trust with integration testing, to make sure the user cannot trick the Python wrapper into synthesizing an input that will cause the core to misbehave or to crash with a bad message).

[axch]

Should also validate that all the input parameters are, in fact, present, or set them to reasonable and documented default values. Fortran namelist input appears to be defined to leave alone variables that are not mentioned in the input file, which will currently have the effect of leaving them uninitialized.

There is a style issue here about how pedantic to be about inputs that are not used, such as the botDrag coefficient in reduced gravity mode. On the one hand, it's nice not to demand the user to supply currently-irrelevant configuration parameters; on the other hand, it's also nice to guarantee that configuration changes are all local (i.e., flipping the RedGrav flag preserves validity of a configuration).