Addition of a scatter-pn response type and a change in the tallying back-end to allow for arbitrary scattering orders

This request includes three major changes to the tallying input and scoring structure specifically for the scattering moments:

1) A new score type, "scatter-p#" was introduced, where # is the scattering order. This differs from "scatter-#" because it automatically generates tallies for scatter-0 through scatter-#. That is, requesting "scatter-p2" is the same as the user requesting scatter-0, scatter-1, and scatter-2. A typical user would typically want all moments up to a certain order and this reduces their burden. This change alone is represented by the first commit on this branch (in a fully tested state, just without the next 2 features).  "scatter-#" still exists and is fully functional. I left this there for backwards compatibility along with the fact that i'm sure i will need to investigate a single moment during the course of the next year of research.

2) The internal workings of the code was revised such that the an arbitrary scattering order can be requested by the user (so long as the legendre moments exist to support it, that is). Specifically, instead of the input processor looking explicitly for "scatter-1", it looks for "scatter-" then reads the number that follows to find out the order (same with "scatter-p1"). This required changing the SCORE_SCATTER_# constant used in score_analog_tally and elsewhere to SCORE_SCATTER_N (and equivalently, changing SCORE_SCATTER_P# to SCORE_SCATTER_PN for the scatter-P# response type).  Also, a new array in the tally class which contains the legendre order associated with SCORE_SCATTER_P/N responses was made.  As before, any number of scatter responses (scatter-# and/or scatter-p#) can be included in a tally in any order.

3) Since it was trivial to do so after the changes in item 2, I increased the maximum legendre order allowed to 10. This is checked during the reading of tallies.xml, and enforced by printing a warning and setting to the maximum if the user wants more than 10.

I've done a bunch of test cases with different tally inputs in different orders and all seems to be working well; this time i've even remembered to change (and test) the statepoints ;-)