Implement support for continuous S(a,b) data tables

This PR addresses the issue identified in issue #211, and thus provides OpenMC with the ability to read thermal scattering tables processed with the iwt=2 option in NJOY.  These tables include a continuous secondary energy distribution for inelastic S(a,b) scatters as are provided in the MCNP6 release as the .2*t tables (i.e., lwtr.20t).  Data using the discrete secondary energies (which OpenMC already supports) are provided (as was the case for MCNP5 as well) as .1*t tables (i.e., lwtr.10t).

 Before this Pull Request can be considered complete, the following tasks must be performed:
- [x] Identify format used for the new S(a,b) data
  * The ACE Format Guide has not been updated to incorporate the format of this data
  * Instead, private communication with Andrew Pavlou (who has authored a paper [PHYSOR 2012] regarding the accuracy of the new format when using MCNP6) revealed that the data should be in a tabular Ein, Eout, mu format, similar to Law 61
  * This information was enough for me to reverse-engineer the format for the data (will discuss details in a comment when I have some more time)
- [x] Implement reading of that format in to OpenMC
  * Since the format was quite different than either an EnergyDist or the information currently stored in the SAlphaBeta class, I had to create a new class just for this information.  SAlphaBeta contains an allocatable list of these objects, which take up minimal space if the continuous data is not a .2*t table
- [ ] Modify physics.F90 to utilize the new data
  * This shouldn't be too difficult, as the format is like Law 61 for secondary energies, and like the discrete inelastic S(a,b) collision physics for the choice of angle
  * A spot of difficulty is what type of interpolation is assumed for Eout.  I will begin by assuming linear interpolation vice histogram, but the format I deciphered doesn't have an INTT-like variable to denote one or the other.  This will probably require experimentation.
- [ ] Sufficiently test the new implementation to ensure the data format was properly reverse-engineered
  * This will probably include running problems similar to those done in Pavlou's paper and observing similar eigenvalue changes
  * The above still isn't going to be the greatest gauge, since his reported eigenvalue differences are ~0.0004.