Implement Arrow-to-Frame Conversion (Deserialization) for Arrow Backend

[arnavdham]

This PR implements the deserialization capability for the Apache Arrow backend, completing the round-trip workflow. It adds support for reconstructing PODIO Frame objects from a single-row slice of an Apache Arrow Table.

Key Features & Changes

• convertTableToFrame API: Introduced a public utility to read and reconstruct a Frame from a specific row of an Arrow Table.
• Auto-generated Readers: Updated cpp_generator.py and generator templates (ArrowMapper.cc.jinja2) to generate deserialization/reader functions for all concrete data model types.
• Complex Type Support: Handles reconstruction of collections, subset collections, vector members, relations/references, and Link Collections.
• Generic Parameters: Reconstructs GenericParameters from the frame_parameters struct column in the Arrow Table.

Testing

• Added comprehensive unit tests in test_arrow_converter.cpp covering:
• Full round-trip (Frame $\rightarrow$ Table $\rightarrow$ Frame) checks.
• Multi-row tables and non-zero row index offset mapping.
• Verification of reconstructed relations, subsets, and parameter maps.

Fixes: #986

[arnavdham]

@jmcarcell Please take a look.

[jmcarcell]

We should only have have to set up the tests once (ideally together with the ROOT ones since the setup is independent of the backend, and the same when checking back the values). Isn't it implied that the previous tests have to work for the table conversion to work, and would not be needed? I'm thinking about the json tests a few lines above.

[arnavdham]

I am not sure what the comment means exactly.

1. Should I remove both the ad-hoc round-trip test(which has manually made frames) and the JSON Equivalence Check, relying entirely on Comprehensive Round-Trip (No-UserData) (which uses makeFrame(0) and verifyEventNoUserData)?
2. Or keep convertFrameToTable Verification / JSON Equivalence Check, refactored to use makeFrame(0) from write_frame.h instead of ad-hoc setup?
   I am thinking the JSON equivalence is not really required now that we have a round trip test.

[jmcarcell]

The round trip test does what the json test does right? Then the json test I think is not needed, I think we talked about this when the json test was introduced. Using makeFrame(0) from write_frame.h would be great; also using the functionality from read_test.h would be great and then we can have a single place where a Frame is created and read.

[arnavdham]

Removed JSON equivalence test and used makeFrame(0)