API Provide generalized detectors in serpentTools.detectors

[drewejohnson]

This PR introduces a heavy re-writing of the detector classes, while seeking to retain much of the previous API. A summary of the changes are provided here

• Detectors can be imported from main API, or from serpentTools.detectors, not serpentTools.objects.detectors
• 🚨 Serpent 1 detectors are not supported - closes API Remove support for SERPENT 1 detectors #327
• 🚨 Detector.indexes is now a tuple of strings, not OrderedDict
• serpentTools.Detector is the base detector, not serpentTools.objects.detectors.DetectorBase
• Detectors can be constructed with only name, some combination of numeric data, or using fromTallyBins class method

>>> d0 = serpentTools.Detector("bare")
>>> d1 = serpentTools.Detector("some", bins=bins, grids=grids)
>>> d2 = serpentTools.Detector(
...     "full", bins=bins, tallies=tallies, errors=errors, indexes=indexes, 
...     grids=grids)
>>> d3 = serpentTools.Detector.fromTallyBins("clsmethod", bins, grids)

• Detector bins, tallies, errors, indexes, and grids are now properties with setters that check for consistency
• CartesianDetector x, y, and z grids are properties
• HexagonalDetector pitch, hexType, and centers [coords] are properties with better setters
• SampledDetector is a true subclass of Detector, no more multiple inheritance
• pytest-style unit test for reader-free detector setup and manipulation

The above changes are also inherited in our subclasses CartesianDetector, HexagonalDetector, SphericalDetector, and CylindricalDetector.

Through the use of properties and some better logic in the plot routines, modifying tally data for plotting is much easier. This closes #337, at least for detectors. Working towards #335 will hopefully fully resolve the spirit of that issue.

The bulk of the changes are in serpentTools/detectors.py and serpentTools/samples/detector.py

Indexes as tuple

The goal for Detector.index is to easily and programatically determine which dimension in tallies and errors corresponds to a specific bin. This makes an OrderedDictionary not well suited, as the only way to retrieve the axis for a specific bin, e.g. energy, is to iterate over all keys until you've hit energy. Secondly, storing an array of the "unique" values, which was really just numpy.arange(nBins), didn't make a ton of sense. We already know how many bins a specific bin type takes up by looking at that dimension in the tally data.

Philosophical justification

The main reason I wanted to do this follows arguments in #335. By generalizing different classes, we are less dependent on how we get the data. This can be Serpent matlab files or some other intermediate storage that we or other users decide to implement.