Generalize the way hardware channels are mapped into detector objects

[paulmking]

Right now, when we construct a detector object, the allowed hardware channel types are basically hardcoded. It would be good if the name of the hardware channel in the channel map file could be used dynamically to assign the proper VQwHardwareChannel-derived class without having to have an explict cascade of if-statements.

Some subtle points:

• A complex detector object (like a stripline BPM) probably should be built with only a single instrumentation type.
• What should happen if we do arithmetic with channels which have different data-structures? All of our channels have at least a single value per helicity window, but some have oversamples. For instance, if we tried to multipy a VQWK value with a scaler value, do we "promote" the scaler to give its value in each subblock, or "demote" the result to only have the hardwaresum?
• What would this do to throughput times? Ideally all of this should be handled once at initialization, but if we have to dynamically generate new objects where we need to determine their types during the running process, it would likely bog us down.

[cameronc137]

See #22 most recent comment and commit f659591, it may be nice to have a generic name for a beam line element (i.e. not an epics variable), so that if you don't know what the device is that is plugged into the ADC, or if the channel is empty, then you can still refer to it in analysis in some useful way. This may require too-generic of an approach to be feasible though.