Trim_toa and Toa_vref updated to run on multiple ROCS (Toa_vref updates taken from Will's work)

[vbe9cs]

Updated TRIM_TOA_SCAN to:
-Fixed issue in the intercepts calculation of the siegel_regression function.
-Reorganized the loops in this command so that the function loops in the following order:
'''
i_roc
--ch
----trim_toa
------CALIB
'''
-Also now can function for multiple ROCs being attached.
-Updated to stop after the first event that is found for each channel that triggers this "high efficiency threshold" (we want to see when the toa starts firing very actively, not just a fluctuation). Also this is all the data that we are using anyways so it is not causing the regression to be worse at all.
-Changed efficiency threshold to be when > 95% of the runs return a non-zero TOA value, to make the slope more accurate to where TOA is fully firing.
-Added portion that saves acquired toa data to a csv file to be analyzed later (using toa_graph.py)
-Decided to set a target calib value of 75, may change in the future but I have found that 70-110 is around when toa starts to trigger depending on the channel.
-Added skip functionality that skips over a channel if it find that the channel had TOA trigger no times over any of my data collection. This channel has the average TRIM_TOA value of channels on its ROC applied to it. If it is truly not firing this should not affect anything negatively, so this is our best guess of what could be applied to it.
-Applied a clamp to the max and min value of TRIM_TOA that is being applied, as to not overload the register with an int that is too large for it to be stored

Added in the toa_graph.py file which can be used with the format:

'''python toa_graph.py toa_efficiencies.csv [i_roc] [ch]'''

This file is intended to be good way to visualize if your data is actually following a linear fit, also can be useful to show if your data is not agreeing with the general "sharp S-curve" shape that we are expecting from TOA efficiency as calib increases. PLEASE NOTE: due to the new portion of the code that breaks after the first high efficiency TRIM_TOA value is found it will be visualized as a line of higher dots that then goes back down to 0, this just means that the scan stopped for this value. You can get far more complete understanding of how that channel is behaving if you remove line 173 of trim_toa_scan.cxx and then do a scan, however this will take significantly longer.

Added changes to the toa_vref scan to apply a TRIM_TOA value of 63 to so that its TOA_VREF value doesn't cause the collected data to dip back into the pedestal range once a TRIM_TOA value is applied. Also applied changes to the CHANNEL_WIDE_CALIB_SCAN to make it more efficient to run, by removing scanning over PHASE_CX and multiple bx values as this did not seem to affect any of the data created.

[tomeichlersmith]

Closing this since it is superseded by #439