Adds Tree Writing to utkscan

[spaulaus]

Description

I solved the Tree/Hist race condition by creating two output files. Trees write to their own file serially, and histograms write to their file asynchronously. Users can define any trees they want in their processors, as long as they do it through RootHandler.

RootHandler

• Reformatted the doxygen comments
• Updated documentation
• Added the tree file for output
• Trees write serially using AutoSave
• We call SetDirectory() on all histograms and trees to help ensure they get registered to the right file
• Updated histograms from integer to doubles.
• Updated if tree in RegisterHistogram()
• Simplified unittest by using ClassName() method for TObjects

  UtkScanInterface

• Updated file naming for consistency

  Anl1471Processor

• Removed unused headers
• Forward declared classes
• Added gamma and vandle trees
• Updated documentation
• Organized headers according to new standard
• Removed all ROOT objects since they're now unused
• Removed ascii output

  TemplateExpProcessor

• Updated documentation
• Removed unused headers
• Removed ascii output
• Updated so that ewe use Trees properly now.

  TwoChanTimingProcessor

• Updated documentation
• Organized headers
• Fixed Tree Definition and Branch Registration
• Removed ascii output

  Related Issue

  137

  Motivation and Context

  We had multiple requests from the stakeholders to allow histogram writing and native tree handling. This was a big limitation in the software. If users defined their own TFile and TTrees in the experiment processor then it would clash with the histogram writing. This lead to segfaults. Without native tree handling users were forced to create hacks around RootHandler to disable histogramming when writing trees to disk.

  How Has This Been Tested?

  I tested this using ANL 1471 experiment data. This test used 5 processors and two trees in the ANL1471Processor. It provided plenty of potential overlaps between TTree::Fill() and histogram writing. I verified everything as working on the CI server. This branch was independently verified by @jjvz

  Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

  Checklist:

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the Contributing document.
• [x] I have added tests to cover my changes.
• [x] All new and existing tests passed.