Fix handling of SPH arrays and database changes between versions

[DCHartlen]

This PR addresses two bugs related to reading SPH data from d3plot files.

First, as noted in issue #67, SPH arrays were not being read correctly. This stemmed from raw SPH data arrays being incorrectly reshaped and indexed. Both of which were fixed in the _read_sph_element_data_flags() function. Note, this PR doesn't address the problem with nodal rigid body also raised in issue #67.

Second, a series of documented and undocumented database changes occurred between older and newer versions of LS-DYNA, which impacted how SPH header data was read. As documented in the 2017 and 2020 databases manuals, the flag isphfg(9) changed from 6 to 12 to output both strain and strain rates. Changes to how state data was read were implemented to handle reading strain and strain rate separately to account for both old and new database versions.

An undocumented change somewhere between R7 and R9 was that isphfg(1) could vary between 10 and 11, depending on whether any history variables were requested in *DATABASE_EXTENT_BINARY. This behaviour was likely why the existing code base threw a runtime error if isphfg(1) did not equal 11, as noted in #34. If isphfg(1) was equal to 10, the junk value in the 11th spot would cause overflow errors when parsing binary data. Parsing behaviour in _read_sph_element_data_flags() for SPH header information was updated to handle cases where isphfg(1) was equal to both 10 and 11.

While not included in this PR, I performed a series of tests on SPH models from Dyna Examples for versions R7.1.2, R9.3.1, and R12.2.1 (both single and double precision), with and without the requested history variables, and obtained correct outputs each time. I didn't include that data here as it was a lot of d3plot files, and I wasn't sure what the copyright situation was using models from Dyna Examples.

[codie3611]

Nice! We tested SPH in an old version in the past, but knew it was a weakspot due to lack of tests.