Create a general photodiode array class

[paulmking]

The injector and PQB laser table test stands will soon be using a 2D photodiode array for laser table setup and characterization.
We need a new class to support decoding, position/width determination, and parity arithmetic.

Describe the solution you'd like
The new class should be an evolution of the QwQPD and QwLinearDiodeArray classes, and likely can be used as a replacement for them.

Some thoughts:

1. Similar to the QwQPD and QwLinearDiodeArray classes, I think it makes sense for this to inherit from the VQwBPM, as the parity arithmetic should be like a BPM (asymmetry of the intensity and differences of the positions and widths). And this is a beam monitor, just for the laser beam.
2. The class should be templated to allow multiple instrumentation channel types, and a typed constructor should be used similar to how the BPMs are constructed. Only one type will be used for all channels in a given instance of the object.
3. I suggest that individual pixels would be named something like "devicename_X_Y", or "devicename_N" for a linear array. I would suggest that pixels be numbered starting from one in each axis, i.e. a QPD would have elements 1_1, 1_2, 2_1, 2_2.
4. I think the instrumentation channels can be defined internally in a single list, with geometry being defined through a geometry map and or through a simple matrixed lookup. This allows the LoadChannelMap to just go through a list and then after all channels are loaded it would figure out what is the geometry of the array, i.e. figuring out the minimum and maximum cells in each dimension.
5. Individual channels would have a pedestal correction for their intensity, and could have a gain but likely we just set the gains to one (or convert raw units to voltage).
6. Geometry could be defined either through a geometry file, or in the absence of a defined geometry it would be expressed in units of the pixel. When using the pixel location, probably make it referenced to the "center" of the pixel array, so we can have positive or negative motion. I guess "positive" motion in the pixel location is the increasing index along a given direction. This could easily be done by defining a "pixel position" for each axis which would be geom=(index - center) where center=(min_index + max_index)/2. So in the case of a QPD, each axis could range from -0.5 to 0.5; if all intensity is in a single pixel the position would be the center of the pixel relative to the center of the array. I guess this pixel geometry could be multiplied by 2 so that the the units are the half-width of each pixel; or that can easily be done with a geometry definition.
7. Would we need to support both a physical geometry and the "pixel geometry" in the same object?
8. In determining the positions, would you want to exclude pixels below a certain threshold, or just weight all pixel locations by their relative intensity?
9. Outputs to trees/ntuples would be the raw pixel intensity, and the calculated centroid positions (and the RMS?). There could be a 2D histogram of the accumulated intensity heat map, or of the centroid position.
10. Would you want other statistical quantities calculated, i.e. skewness, kurtosis, etc, assuming there are enough pixels along a particular axis for it to make sense? Will there be enough pixels for those sorts of quantities to make sense?