FlashLFQ refactoring to enable generic peak operations

[Alexander-Sol]

Added an interface, ISingleScanDatum and and abstract class, TraceablePeak, to enable the generic use of pre-existing FlashLFQ functions.

ISingleScanDatum

• Defines the behaviour that a single datapoint is expected to have, e.g., mz, index, separation (retention time)
• Examples are IndexedMassSpectralPeak, IsotopicEnvelope

TraceablePeak

• Contains a list of ISingleScanDatum object
• Implements a default CutPeak method
• Provides a static FindPeakBoundaries method that should be useful

[codecov]

Codecov Report

Attention: Patch coverage is 89.65517% with 9 lines in your changes missing coverage. Please review.

Project coverage is 77.77%. Comparing base (e4dda42) to head (2711f04).

Files with missing lines	Patch %	Lines
mzLib/FlashLFQ/Interfaces/TraceablePeak.cs	90.19%	4 Missing and 1 partial ⚠️
mzLib/FlashLFQ/IndexedMassSpectralPeak.cs	66.66%	2 Missing ⚠️
mzLib/FlashLFQ/ChromatographicPeak.cs	96.00%	0 Missing and 1 partial ⚠️
mzLib/FlashLFQ/IsotopicEnvelope.cs	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #837      +/-   ##
==========================================
- Coverage   77.78%   77.77%   -0.02%     
==========================================
  Files         230      231       +1     
  Lines       34152    34170      +18     
  Branches     3538     3540       +2     
==========================================
+ Hits        26566    26576      +10     
- Misses       6983     6990       +7     
- Partials      603      604       +1     

Files with missing lines	Coverage Δ
mzLib/FlashLFQ/FlashLfqEngine.cs	92.18% <100.00%> (-0.29%)	⬇️
mzLib/FlashLFQ/ChromatographicPeak.cs	97.90% <96.00%> (-0.39%)	⬇️
mzLib/FlashLFQ/IsotopicEnvelope.cs	81.48% <66.66%> (-1.86%)	⬇️
mzLib/FlashLFQ/IndexedMassSpectralPeak.cs	92.00% <66.66%> (-8.00%)	⬇️
mzLib/FlashLFQ/Interfaces/TraceablePeak.cs	90.19% <90.19%> (ø)

[nbollis]

I wonder if these interfaces should be in projects above FlashLFQ so that packages that FlashLFQ uses could implement these interfaces for use in FlashLFQ functions

[nbollis]

Should we use retention time here instead?