IMT code segfaults when branches are changed

CMS encountered a case where, when a branch is added to a Tree in the middle of processing, the IMT code for TTree::Flush triggers a segfault.  See https://its.cern.ch/jira/browse/CMSCOMPPR-3348

From Chris Jones:

The problem appears to be the TTree has an inconsistent list of branches. I'm running the job in the debugger with a debug version of ROOT. The relevant place for the crash is here:

https://github.com/root-project/root/blob/v6-12-00-patches/tree/tree/src/TTree.cxx#L4998

 

The branch being worked on is at entry `j` which is 909. However, if we get the size of `fSortedBranches` we get

     (gdb) print fSortedBranches.size()

     $9 = 893

 So clearly we are getting a value outside the range of the number of branches in the sorted list.

I believe the problem is here:

https://github.com/root-project/root/blob/v6-12-00-patches/tree/tree/src/TTree.cxx#L4971

the fSortedBranch list is only guaranteed to be the same size as the internal list of branchs in the TTree

https://github.com/root-project/root/blob/v6-12-00-patches/tree/tree/src/TTree.cxx#L4966

the first time this routine is called. Since Andrea said they add more branches later, which can happen after a `TTree::FlushBaskets` is called, then `fSortedBranches` is no longer the correct size and we read off the end of the container.

Seems that the fSortedBranch cache ought to be invalidated each time a branch is added or removed.  Looking quickly at the code, I expect it is possible to trigger the segfaults on reads too.