Corrupt input trees

[lk11235]

Quality-of-life addition to check for corrupt input trees before processing. Zombie checks are already implemented, but checking for corruption of any events is more thorough. See #30 for an example case where this might come up.

[lk11235]

Actually, the updates proposed in #31 could "fix" this. A fantastic solution might be to stream all data into nice objects first, then check for corruption. Assuming that events are randomly corrupted, we could remove the offending events and "fix" the xsec/weights of the processed tree to reflect the fewer number of MC events. While raising the issue as a warning to the user and detailing the stripped events and changes to weights, this could effectively patch-up any damaged CJLST trees at the point of processing.

[lk11235]

Actually, the updates proposed in #31 could "fix" this. A fantastic solution might be to stream all data into nice objects first, then check for corruption. Assuming that events are randomly corrupted, we could remove the offending events and "fix" the xsec/weights of the processed tree to reflect the fewer number of MC events. While raising the issue as a warning to the user and detailing the stripped events and changes to weights, this could effectively patch-up any damaged CJLST trees at the point of processing.

Streaming all the events directly will not work. An event loop must be utilized to catch errors and identify any damaged events. Then they can be removed by EventNumber and the rest of the distribution can be corrected appropriately. Assuming random damage in the CJLST trees, this proposed procedure would reasonably maintain the priors in damaged trees so that they can still be used for analysis.