Add validation to case settings where appropriate

I have noticed a handful of case settings that have implied bounds on their ranges, but no check is ever done to confirm the user input a valid value. For instance, burnSteps, nCycles, and power should all be non-negative but nothing stops the user from entering negative numbers.

In all of these instances, the code crashes somewhere where it is not necessarily clear what caused the crash. And in all instances, we could easily set a bound on the possible input values using the schema attribute when each of the Settings are defined and using some of the built-ins of Voluptuous (which we are already using). The schema for these cases would look something like voluptuous.Range(min=0). Very easy to add in.

I think it would be worthwhile to go through the case settings and add simple validators where they are not currently in place.

Does anybody have any objections to me doing this?

[keckler]

Checklist of settings to add validation:

From globalSettings:

Setting	Range	Implemented	Tested
numProcessors	>= 1	Y	Y
axialMeshRefinementFactor	> 0	Y	Y
minMeshSizeRatio	> 0	Y	Y
cycleLength	> 0	Y	Y
availabilityFactor	>= 0	Y	Y
burnSteps	>= 0	Y	Y
beta	0 =< f_i <= 1	Y	Y
decayConstants	lambda_i >= 0	Y	Y
buGroups	0 < p_i <= 100	Y	Y
burnupPeakingFactor	>= 0	Y	Y
startCycle	>= 0	Y	Y
startNode	>= 0	Y	Y
lowPowerRegionFraction	0 <= F <= 1	Y	Y
mpiTasksPerNode	>= 0	Y	Y
nCycles	>= 1	Y	Y
numCoupledIterations	>= 0	Y	Y
power	>= 0	Y	Y
skipCycles	>= 0	Y	Y
targetK	>= 0	Y	Y
acceptableBlockAreaError	> 0	Y	Y
independentVariables	list of tuples of length 2	will not do	N/A
Tin	> -273	Y	Y
Tout	> -273	Y	Y

From databaseSettings:

Setting	Range	Complete	Tested
dbStorageAfterCycle	>= 0	Y	Y

From reportSettings:

Setting	Range	Complete	Tested
timelineInclusionCutoff	0 <= f <= 100	Y	Y

[keckler]

See #595 for the PR.