Save new Reactions_Type data after a simplified SDC burn

[dwillcox]

@jmsexton03 has reported that for Simplified SDC in the flame problem, enuc in the plotfiles is identically zero. This is not the case for Strang and the reason appears to be a bug.

This PR will ensure new Reactions_Type data is saved after the burn properly so enuc will be saved into the plotfiles correctly, corresponding to the value at the last SDC iteration. It should not change the estimated timestep because we aren't currently using Reactions_Type to do so.

To elaborate:

Currently in Simplified SDC, Castro::react_state() sets the new Reactions_Type data (R_new) in ca_react_state_simplified_sdc.

There we update Unew using the results of the burn, however, right before returning from react_state() we overwrite the burn results in R_new with the old values in Reactions_Type in R_old in the MultiFab::Copy().

This was done in 3460254 because at that time the burning timestep estimator required the Reactions_Type data to be defined. (Although even then it seemingly makes more sense to save R_new back into R_old after the burn instead of vice versa?).

As of 37e048c the timestep checking logic no longer requires the Reactions_Type data in the deprecated ca_check_timestep. We are just calling the actual_rhs to get an instantaneous value for d(Enuc)/dt. Although in Castro::estTimeStep() we are passing R_new into ca_estdt_burning, it remains unused there.

[maxpkatz]

Although even then it seemingly makes more sense to save R_new back into R_old after the burn instead of vice versa?

Your confusion there is because we used to store the simplified SDC burn in R_old for reasons I don't remember. That was changed relatively recently (af8b9cf ), but I missed this bit in react_state when I did that.