lalaps_spec_avg_long new autoTrack feature returns incorrect line history data

(Assigning to Evan per his request.)

Example set of arguments to reproduce the bug, using some SFTs generated for Fscan development at CIT:

--SFTs=/home/abby.wang/public_html/fscan/4hours/20200206-000000/H1_GDS-CALIB_STRAIN/sfts/H-1_H1_1800SFT-*-1800.sft --IFO=H1 --startGPS=1264982418 --endGPS=1264996818 --fMin=10.0 --fMax=200.0 --timeBaseline=1800 --outputBname=temporary-linetrack --autoTrack=0.75 --persistSNRthresh=3.0

This produces, for example, a tracked line at 140.253 Hz. The corresponding "standard deviations above mean" data appears to be [ 0.3992 0.4087 0.246 -0.1295]. None of these exceed the SNR threshold, indicating that the line should not have been tracked.

The problem appears to be in lines 299-303 (here) of the source code where the frequency value of a newly tracked line is converted to a string and appending to whatever tracking list was supplied by the user. It looks like that introduces some rounding which sometimes causes an adjacent frequency bin to be tracked instead.

I fixed this temporarily on my local copy of the code like this, but I'm not sure if it's the tidiest way to do it:

        if (XLALUserVarWasSet(&auto_track) && (persistency->data[i] >= auto_track)) {
            char val_as_str[50];
            XLAL_CHECK_MAIN( snprintf(val_as_str, sizeof(val_as_str), "%16.8f", f0 + deltaF*i) >= 0, XLAL_EFUNC);
            XLAL_CHECK_MAIN( (line_freq = XLALAppendString2Vector(line_freq, val_as_str)) != NULL, XLAL_EFUNC );
        }