Implementing SimEnergyDeposit filter for ICARUS variation studies in release tag version v09_89_01_01

[jzettle]

Description

Please provide a detailed description of the changes this pull request introduces. If available, also link to a docdb link where the issue/change have been presented on/discussed.
This pull request introduces a larsoft module that can be run during the detsim stage to filter out SimEnergyDeposits around a rectangular volume and creates a new SimEnergyDeposit collection (with a different name, sedfilter) that can be passed to the downstream WireCell processing. The goal of this is to allow for a systematic variation sample that addresses the fact that the induction 1 wire gap at z = 0 is not simulated in the icarus geometry. This PR does not change anything with the standard ICARUS or SBND simulation and the module is completely optional to include.

This PR addresses the module and a companion PR in icaruscode (SBNSoftware/icaruscode#778) addresses the fcl configuration and WireCell configuration options of running it as a variation sample.

• Have you added a label? (bug/enhancement/physics etc.)
• yes
• Have you assigned at least 1 reviewer?
• yes
• Is this PR related to an open issue / project?
• yes, for ICARUS systematics studies for the first oscillation analysis, Gap in tracks at boundary of induction 1 plane icaruscode#769
• Does this PR affect CAF data format? If so, please assign a CAF maintainer as additional reviewer.
• no
• Does this PR require merging another PR in a different repository (such as sbnanobj/sbnobj etc.)? If so, please link it in the description.
• yes, there is a companion PR for icaruscode that includes fcl files and wirecell configuration options in order to run this as a systematic variation (Feature/jzettle sedfilter icaruscode#778)
• Are you submitting this PR on behalf of someone else who made the code changes? If so, please mention them in the description.
• no, this is largely my own work with discussions with @jzennamo

[ibsafa]

@jzettle thanks for creating both this and the PR against develop. Once these changes are approved, I can release a patch to v09_89_01_01 and include these changes in the next release based on the develop branch.

[jzettle]

There were comments from @PetrilloAtWork on PR #486 which identically apply here. I am almost done addressing those and can update once that is completed

[jzettle]

Okay the merging of develop into this branch has caused a lot of problems in updating this based on the comments I received. I will need to understand what I can do to recover and push the changes I need to

[jzettle]

I resolved it and was able to push the updates based on @PetrilloAtWork but now I'm concerned about getting this into a patch of v09_89_01_01 based on new things that are now in this branch. I hope my concern is unfounded.

[jzettle]

Closing this as it got complicated. Will wait until we have the new release branch in place before requesting another PR against it