Feature/blip energy drift correction

[Jjm321814]

Adding additional blip energy variables so analyzers have access to a drift corrected energy, as well as an explicitly not drift corrected one.

All drift corrections are anchored to the event timestamp, so the beam blips will come out with the right energy. Any out-of-time blip activity will be mis-corrected, so the noDriftCorrection variables are saved as new variables.

[Jjm321814]

This PR is part of a set of 4 in sbndcode, sbnobj, sbncode, and sbnanaobj to make this new blip data entry, and share it to CAF level.
Each PR is at
sbndcode: #941
sbnobj: SBNSoftware/sbnobj#174
sbncode: SBNSoftware/sbncode#661
sbnanaobj: SBNSoftware/sbnanaobj#193

[Jjm321814]

Initial checks on MC looked good. The values of energy were very mildly shifted with temporary debug print outs like

 dep El before corr 1767.8
0.0615994
 dep El after corr 1767.88
Blip Time1.55457 Det Lifetime 35000
0.0615994
 finally blip energy 0.0616021

Unfortunately the detector properties service used to get the electron lifetime initially applies a fixed lifetime. We will need to connect to some kind of calibration database service to get better results on data.

[Jjm321814]

This PR is more complicated.
Applying the blip drift correction in data required some interface to the NormalizeDriftSQLite_tool. That was added in to the blipAlg files.
But I don't know how to use an art_tool, so I changed the implementation of NormalizeDriftSQLite_tool so it has an additional class implementation that can be imported more easily.
To avoid code duplication I split the actual definition and implementation code into their own files that get imported. CMakeLists needed updated to accommodate these changes.

This PR does not interrupt PANDORA's use of the NormalizeDriftSQLite_tool and allows blips to use NormalizeDriftSQLite_class. If we have an example of implementation of the art_tool version (that doesn't result in the code duplication seen in

sbndcode/sbndcode/Calorimetry/LightCaloProducer_module.cc

Lines 821 to 848 in 27d88f5

	sbnd::LightCaloProducer::ELifetimeInfo sbnd::LightCaloProducer::GetELifetimeFromDB(uint64_t run) {
	// Check cache first
	if (felifetime_cache.count(run)) {
	return felifetime_cache.at(run);
	}
	// Query database - translate run into fake "timestamp"
	// (same convention as NormalizeDriftSQLite)
	felifetime_db->UpdateData((run + 1000000000) * 1000000000);
	ELifetimeInfo info;
	double tau_E, tau_W;
	felifetime_db->GetNamedChannelData(0, "etau_sce_spatial_east", tau_E);
	felifetime_db->GetNamedChannelData(0, "etau_sce_spatial_west", tau_W);
	info.tau_tpc0 = tau_E*1e3; // the db value is in ms, convert to us
	info.tau_tpc1 = tau_W*1e3; // the db value is in ms, convert to us
	if (fverbose) {
	std::cout << "[LightCaloProducer] : Electron lifetime from DB for run " << run << std::endl;
	std::cout << "[LightCaloProducer] : TPC0 (East): " << info.tau_tpc0 << " us" << std::endl;
	std::cout << "[LightCaloProducer] : TPC1 (West): " << info.tau_tpc1 << " us" << std::endl;
	}
	// Cache the result
	felifetime_cache[run] = info;
	return info;
	}

) I'd be happy to simplify this PR to that suggestion.

[Jjm321814]

Oh oops let me get rid of the print statements I used to check the implementation.

[Jjm321814]

I have verified this code imports the correct lifetime values and adds additional variables to the blip larsoft output (reco2) and SRBlip output (CAF).
The validation was done on 10 data events from one run and 10 MC events.