Global decay off

This implements an optional flag that allows the user to disable the material class' Decay function. This is intended to fix issue #984 which complains of an inability to globally turn off decay (at the very least)

As we discussed before on a development call, this feature simply adds the option to allow or specifically not allow the use of the Decay function in the material class.

Further granularity of options or implementation of global decay was not supposed to be part of this quick fix. In the future, this work can be extended to re-implement the feature in which decay occurs whenever a material composition is queried. However, that implementation of global decay was supposed be left up to further discussion on what folks decide was the best course of action.

This PR focuses on adding the decay flag to the SimInfo object and using that flag in the material class' decay function. 

There are all sorts of subtlety surrounding direction of compatibility.
 Forwards compatibility is allowing older versions of cyclus to work with
newer valid cyclus artifacts - e.g. using an older version of cyclus to run
a newer input file or initialize from a newer database.  Backward
compatibility is running an older input file or initializing from an older
database with a newer version of cyclus. I don't think we should bother
with forwards compatibility (and almost no software project does).  There
is nothing I'm aware of in the kernel that breaks backward compatibility by
adding new columns.  Except the dumping of data from a newer simulation to
a pre-existing database with data from older simulations - which is a fuzzy
area w.r.t. being actual breakage.


On Tue, Sep 2, 2014 at 12:30 PM, Matthew Gidden <notifications@github.com>
wrote:

> In src/context.cc:
>
> > @@ -133,6 +136,7 @@ void Context::InitSim(SimInfo si) {
> >        ->AddVal("Handle", si.handle)
> >        ->AddVal("InitialYear", si.y0)
> >        ->AddVal("InitialMonth", si.m0)
> > +      ->AddVal("DecayAllowed", si.decay)
>
> I'm +0 for end-of-table column addition as non breaking, pending
> @yarden-livnat <https://github.com/yarden-livnat> or @hayagur
> <https://github.com/hayagur> 's confirmation that this doesn't break
> existing cyclus/cyclist2 functionality. It's my understanding that this
> will break HDF5's backwards compatibility whether or not its a column or
> table, right? That is, if a column, the table's field_types is
> incompatible, and if a table, it will not exist pre 1.1?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/cyclus/cyclus/pull/995/files#r17001716>.
>