[treeplayer] Fix array reading of typedef leaves via branch.leaf syntax

[guitargeek]

TTreeReaderArray<ULong64_t>(r, "x.x") failed with "Leaf of type ULong64_t cannot be read by TTreeReaderValue", while the plain branch name "x" worked.

TTreeReaderArrayBase::GetBranchAndLeaf() matched the leaf type against the reader type by comparing TDictionary object identity. For a typedef'd fundamental such as ULong64_t, the leaf's TDataType is the typedef itself (GetTypeName() returns "ULong64_t", not the resolved "unsigned long long"), so the looked-up dictionary differed from fDict (the "unsigned long long" TDataType) and the match failed even though both denote the same fundamental type.

Compare the underlying EDataType instead, mirroring what TTreeReaderValue already does. This fixes ULong64_t and every other typedef'd fundamental.

Closes #9758.

🤖 Done with the help of AI.

[dpiparo]

Thanks for digging this out. To me the change looks appropriate, also because it realigns TTreeReaderValue and TTreeReaderArray. I would like to ask the opinion of @vepadulano , who has a demonstrated experience with the TTreeReader federation of classes.

[github-actions]

Test Results

    23 files      23 suites   3d 16h 7m 20s ⏱️
 3 875 tests  3 875 ✅ 0 💤 0 ❌
78 940 runs  78 940 ✅ 0 💤 0 ❌

Results for commit e306353.

[vepadulano]

This is a verbatim copy of the logic used in TTreeReaderValue at

root/tree/treeplayer/src/TTreeReaderValue.cxx

Line 436 in 7a23951

if (tempDict && fDict->IsA() == TDataType::Class() && tempDict->GetType() == ((TDataType *)fDict)->GetType()) {

, which makes sense.