Issues reported by coverity:
 - https://coverity.cern.ch/query/defects.htm?projectId=10001&cid=98864
 - https://coverity.cern.ch/query/defects.htm?projectId=10001&cid=98876

When noting that a TStreamerInfo set has already been processed, we
must do it in 3 separates steps:
  - check it was seen before
  - read and process the set
  - record that the set as been seen.

The previous situation:
  - check and record that the set as been seen
  - read and process the set
led to a race condition if a second thread was checking the same
set before the second step was completed (in which case the
second thread was believing that the set was process and looking
for the result of the process (one of the StreamerInfo) but could
not find it.

We extend RConcurrentHashColl to have 2 new operations
  - standalone Hash calculation
  - standalone Find of hash
  - standalone Insert of hash.
and we use it to split the check and the recording as described
previously.

(this is an addendum to 95bf468438)

Fix error: redefinition of module 'TSAXParser.h' for cxxmodules

This is an additional fix for https://github.com/cms-sw/cmssw/pull/22594

If one of the class associated with a TBranchElement has a base class and/or sub-object class that
has a rule that requires a cache (onfileObject) object to stage the original data *but* does not
have branch in the TTree that also neeed the same cache object, we need to associate a cache
object with the StreamerInfoAction sequence that needs it (associated with a higher level branch)
and give it ownership of this cache object)

At this place buffer was allocated using length of source string.
gcc does not like when strncpy length argument directly derives from
source string length. Actually, buffer should not depend from source
length - here it was workaround for old problem, which is already fixed.
Therefore just use constant buffer length

Solves https://sft.its.cern.ch/jira/browse/ROOT-9588

This reverts commit 41258f7c.
This commit breaks C++11 builds with the following error:

include/ROOT/RMakeUnique.hxx:28:64:
   error: invalid use of array with unspecified bounds

On certain Windows builds, `return {..., true}` would create a local SequencePtr, return a copy, then destruct the local - which in turn would delete fSequence. Instead, move the local and remember that the local has lost ownership.

Introduce dummy for it

If current pointer changes due to reallocation offset can be used as is

position

Instead of assigning rule that do not correspond to any specific branches
(for example rules setting transients or whole objects) to an hypothetical
'previous' branch, we switch to assign those orphan rules to either the
non-data bearing branches (split single objects or bases) or the collection
node (since the splitting completely flatten the hiearchy in this case).

This requires enhancing the list of IDs from a single list of element index
in the 'sole' current StreamerInfo to a nested list of elements that carries
along the sub-StreamerInfo information.

The callback mechanism as implemented is not what is needed by CMS,
as previously thought. In order to allow the final goal of avoiding
oversubscription of the machines on which the TBufferMerger is used
within a framework, this functionality is better removed in order to
allow doing away also with the separate output thread currently needed
by TBufferMerger.

in case gDebug is greater than 0.

it is not necessary to deserialise the streamerinfos and interact with the
type system if we did all this work already. This is visible for example when
opening and closing several small files through a TChain in a MT environment.
With this fix we keep track of the blob of bytes representing streamer info records
that we read and in case a blob has been already processed, no work is carried out.
The hash function used is sha256, therefore collisions do not take place.

Removing obsolete code from TFile(compression algorithm and level of StreamerInfo should the same as in TFile)

Note: This read was however harmless as the loop cut short immediately thereafter
without using the result of the read.

JSON does not have proper representations of such values, therefore just
use something which can be decoded by parsing. Of course, decode should
be aware of such problem. When reading with TBufferJSON, null values
from JSON converted into NaN

This reverts commit 9d226a34.
This interferes with counting the tasks in a way that breaks the test.

This makes it again as it was previously implemented by Vassil
in commit 92f1f502. Suggested by Enrico as easier to read.

If a task triggers another task, and we don't count them before
launching them, they may never be counted, which will result in
an infinite loop. This only happens in single-threaded mode, that
is, when TTaskGroup just calls the function instead of using TBB.