Feature/adding blip to caf

[Jjm321814]

Moved the blip-related structs and classes to sbnobj.
This PR must not be approved until SBNSoftware/sbnobj#155 is approved/released! Otherwise it will break blip production.
I also had to make a few CRT changes to successfully compile off the current sbnobj file.

https://sbn-docdb.fnal.gov/cgi-bin/sso/ShowDocument?docid=44445

[Jjm321814]

Adding a comment to each of these to track all 4 related PR.
sbncode: SBNSoftware/sbncode#603
sbndcode: #871
sbnobj: SBNSoftware/sbnobj#155
sbnanaobj: SBNSoftware/sbnanaobj#173

The changes to sbnobj, and sbnanaobj are fully independent of any other changes, so they can be approved first.

sbndcode changes rely on sbnobj, so it will have to wait for the first approval. A later simple PR will delete the (now duplicated) class files in the BlipUtils folder here

sbncode changes rely on both sbnobj and sbnanaobj, so that will have to wait for both of the first two approvals.

[henrylay97]

Hi @Jjm321814 can you remove the CRT changes from this PR and instead merge in develop which has the required updates needed to be compatible with the sbnobj changes. Thanks!

[Jjm321814]

Merged in develop. Testing Compile now

[Jjm321814]

Compiled fine

[Jjm321814]

Let me make fcl changes to the cafmaker, but a dumped fcl version worked fine

[Jjm321814]

Pushed all the fcl changes needed to run CAF on data and MC.
Have only tested on data. We see a 19% increase in the size of a standard CAF data file (3.7 MB to 4.4 MB) because of blips

[henrylay97]

Hi Jacob, I will review properly after tomorrow's reconstruction meeting. In the meanwhile there are still changes to CRT and LightPropagation files that shouldn't be necessary. Can you remove these? Thanks!

[Jjm321814]

Im having a new runtime error
/cvmfs/larsoft.opensciencegrid.org/products/root/v6_28_12/Linux64bit+3.10-2.17-e26-p3915-prof/etc/cling/std.modulemap:312:10: error: module 'std.span' requires feature 'cplusplus20' module "span" { ^ /cvmfs/larsoft.opensciencegrid.org/products/range/v3_0_12_0/include/range/v3/range/concepts.hpp:25:10: note: submodule of top-level module 'std' implicitly imported here #include <span>
after the commits submitted today

[Jjm321814]

Okay got the code to run again! Almost all the TVector3 instances have been removed from the intermediate processing too.
The geo::vect::MiddlePointAccumulator object was causing a bunch of run time issues, so I kept the explicit use of for loops to find middle points and weighted averages.

The one place TVector3 remains is in calculations of closest points to lines. I can update that if requested.

I will verify the outputs look good on several Fall production files tomorrow/Thursday now that the code is in a basically working state.