NDPP Refactorization to increase performance and reduce memory burden required by downstream MC code

This pull request represents three different efforts, all geared at reducing NDPP runtime and decreasing the memory needed by the downstream monte carlo code at runtime. These changes are:
* Split the elastic and total inelastic data in to separate output in the written libraries.
  - Elastic data is the only temperature-dependent portion of the data, so separating it out minimizes that which must be redundantly stored by MC code.
  - Elastic resonances force many points to be needed in the incoming energy grid in order to better interpolate the data; since the MC code will combine the two at run time and will use the x/s data available to determine the ratio of elastic to inelastic, these points which exist only for resonance x/s variation are no longer needed in the NDPP data.
  - In the end, the total library size did not change much (some shrunk, some grew), but the important part here is that the elastic part is now typically < 1MB per temperature (the inelastic can still be as large as 100+MB)
* Before, incoming energy points needed to better interpolate inelastic energy reactions with outgoing distributions near group boundaries were added by saying 'meh, just add 50 points for every point currently on the grid and rely on grid thinning to remove the extraneous ones later'. Now we use NJOY's critical points determination formulation to find what range these points actually need to be at.
  - Benefit of this is less NDPP run time and theoretically better accuracy
  - Total memory usage didnt drop significantly if the user used grid thinning since the extra points were removed anyways.
  - Still have to evaluate which number of points is best to use w/in the critical energy range.
* Cleaned up print tolerance code to exist in its own subroutine and call that before doing grid thinning
  - Also desirable to do it before grid thinning so that the grid thinning might be able to take advantage of the additional sparsity and remove more points.
  - This was only worth a few percent memory reduction at best, but still desirable for code organization.