[ntuple] Extend RNTupleOpenSpec to allow creating processors from a TDirectory

[enirolf]

This PR changes RNTupleOpenSpec to accept a TDirectory (or one of its descendants) instead of a plain file name, and create a RNTupleProcessor from there. This provides more flexibility for creating RNTupleProcessor objects. Among others, it enables processing RNTuples stored in subdirectories and TMemFiles.

One caveat is that the use of std::variant is not very ergonomic in Python. After discussing different solutions with @vepadulano, we concluded that the specification would/should not be used for anything beyond creating RNTupleProcessors, and that public access to its data members is not strictly required. It has therefore been changed to a write-only class, and the RNTupleProcessor creation factory arguments have been updated accordingly.

[github-actions]

Test Results

    18 files      18 suites   4d 10h 2m 41s ⏱️
 2 725 tests  2 724 ✅ 0 💤 1 ❌
47 351 runs  47 350 ✅ 0 💤 1 ❌

For more details on these failures, see this check.

Results for commit 78c02dc.

♻️ This comment has been updated with latest results.

[vepadulano]

I think we need to discuss a bit the public interface of this. I am not sure it's going to be easily usable from Python, which might or might not be what we want.

[hahnjo]

As an alternative interface, maybe we can accept a RNTuple anchor directly (only for RNTupleSingleProcessor?) and require the user to compose that?

[enirolf]

As an alternative interface, maybe we can accept a RNTuple anchor directly (only for RNTupleSingleProcessor?) and require the user to compose that?

I'm not very fond of that idea because 1) it would put more burden on the user and 2) I don't know to what extent that would make things nicer in Python. Of course when it turns out that this is a desired interface by users we can add it, but for now I would prefer not to extend the interface.

I discussed possible solutions with @vepadulano, and ultimately we settled on making RNTupleOpenSpec write-only (and making them pass-by-value in the factories). We anyways don't expect users do anything with the spec except create processors and this removes the possibility of having a not-easy-to-use-in-Python variant exposed. Again, only time will tell if this is actually what we want, but it at least keeps the current interface consistent.