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. 

>  But, in the hdf5 backend, for example, you probably would just directly map onto the database structure. Is that what's going on?

@katyhuff  - Well, for the HDF5 backend we have to dynamically create the dtype so that it is compatible with the Backend API. Though you state exactly my point - the struct that represents the table would have to change! This is bad for any user of cyclus.

> I think appending columns to tables should be allowed as non-API breaking

> I'm +0 for end-of-table column addition as non breaking,

@rwcarlsen & @gidden - it  is breaking an interface, if not an API!  I am looking at this problem not from a cyclus kernel perspective (which is robust to the issue as @rwcarlsen pointed out), but from the point of view of someone writing cyclus analysis tools.  

I posit that *any analysis tool that is written for version 1.x should work on both v1.(x-1) and v1.(x+1).* No special casing should have to happen in an analysis tool because of a cyclus version number  That is what stability means, especially for core tables. And this is a core table. The concern here is that if we allow this kind of interface change to happen even once, there is the impetus to let it happen over and over again. This creates an ever-growing headache of special cases for the analysis tool author to contend with. In particular we should never ever change the table that tells us which cyclus version we were made with, which also happens to be this table!

That said, if we had an official analysis tool that was robust to these kinds of table changes then I would be more open to this. I still think I would be against it on principle, but at least there would be a solution in practice. Right now we have no solution and no concrete plans for one. I feel that we need to be especially careful and vigilant.  

I agree with @rwcarlsen that we don't need to be forwards compatible. This PR breaks that in a serious way and I think it is a good idea. But I do think that we need to extend backwards compatibility to other parts of CEP2 that aren't the simulator itself.  I am strongly in favor of having a single analysis package nucleate and modifying the interface over minor version numbers significantly raises that bar.