add another Functional transformer: SplittingMergingTransformer

@sponce, @rmatev, @nskidmor : FYI -- I have a use-case for this type of algorithm in mind, and that is to centralize the handling of the raw_event_format. With this as a base class, one can generalize UnpackRawEvent (which is a SplittingTransformer which takes a single RawEvent as input and produces a number of RawBank::Views as output) into UnpackRawEvents, which will take a number of RawEvents as input, and produces a number of RawBank::Views as output. Now, this could already have been achieved by using one UnpackRawEvent per input RawEvent, but with this as base class only a single instance is needed to do the same thing.

Basically, a single UnpackRawEvents instance would be be the only thing that needs to know about raw_event_format -- provided all the current algorithms which still consume RawEvent(s) are switched to consuming the actual RawBank::View(s) they really want instead...

added 1 commit

563dde44 - add SplittingMergingTransformer

Compare with previous version

added 1 commit

78521268 - add SplittingMergingTransformer

Compare with previous version

added 1 commit

e8d38a17 - add SplittingMergingTransformer

Compare with previous version

mentioned in merge request lhcb/LHCb!3457 (merged)

@clemenci: the ci-test failed here because in pytest options dump it shows:

E             Omitting 22 identical items, use -vv to show
E             Differing items:
E             {'IntVectorsToInts': {'InputLocations': ['/Event/EventInts', '/Event/OddInt', '/Event/Fib7'], 'Mapping': [[0, 0], [0, 1], [0, 2], [1, 1], [1, 2]], 'OutputLocations': ['/Event/EvenOddFib', '/Event/OddFib']}} != {'IntVectorsToInts': {'InputLocations': ['/Event/EventInts', '/Event/OddInt', '/Event/Fib7'], 'Mapping': [(0, 0), (0, 1), (0, 2), (1, 1), (1, 2)], 'OutputLocations': ['/Event/EvenOddFib', '/Event/OddFib']}}

I don't know what it is comparing to what, but given that the Mapping property of the algorithm I added has a vector<pair<int,int>> as payload I think that the correct version is the one with [(0,0],...] -- so would be good to know what format is dumping this as [[0,0],...] and thus doesn't distinguish between eg. pairs and lists...

Anyway, this MR is not the source of the problem, it just seems to be the first one to expose it...