QwCorrelator will need its own RNtuple support functions

[paulmking]

After merging PR #123, when running with RNtuples not enabled, there are two warnings generated by qwparity refering to RNTuples not being created for the QwCorrelator objects:

Warning: No data handler output; not creating RNTuple lrb_std
Warning: No data handler output; not creating RNTuple burst_lrb_std

This seems to be because the default behavior for a data handler class is that it uses the size of the output variable array to determine if it should create and fill TTrees or RNtuples, and the QwCorrelator overrides those functions for TTrees but has no defined override for RNtuples.

We did not previously see these messages, because we had wrapped the data handler array calls to ConstructNTupleFields in a test of the global QwOptions "enable-rntuples" flag.

When we get down to actually trying to construct TTrees or RNtuples, we do test against the appropriate locally stored flag in the QwRootFile object. For the data handlers, this happens for each datahandler individually when it makes a QwRootFile function call. All non-data-handler trees/rnutples are dealt with by direct QwRootFile calls from the QwParity main routine.

Some thoughts:

1. We could add a function to return the QwRootFile's "enable/disable" status for TTrees and RNtuples, and either use that to exit the data handler array functions before looping through the data handlers and only then realizing the trees or ntuples were disabled. We'd still need to implement proper RNtuple support functions for the QwCorrelator class.
   --> This could save a little processing time just because we don't have to get into each data handler and only then check the QwRootFile status values. But I don't expect it makes a big difference.
2. Don't bother checking for "enable/disable" outside of the QwRootFile class. Just implement proper RNtuple support functions for the QwCorrelator class.
   --> This is probably sufficient, and anyway doing this by itself could be the first step in testing the first option.

[wdconinc]

See #191.

Other thought:

• We treat the data handlers differently and could streamline the code here (for both ttree and rntuple). For subsystem arrays we do:

  treerootfile->ConstructNTupleFields("evt", "MPS event data RNTuple", ringoutput);
  

  But for data handler arrays we do:

  datahandlerarray_evt.ConstructNTupleFields(treerootfile, "evt_");
  

  This means that the ConstructNTupleFields calls for data handler arrays do no have access to the parsed options inside the QwRootFile (including knowledge of whether rntuples are enabled).

  I think we should just use QwRootFile::ConstructNTupleFields which is a template anyway.