Add multimodal detector datasets (LArTPC + Water Cherenkov)

[OmarAlterkait]

Add LArTPCDataset and WCDataset for loading multimodal detector simulation data through pimm's existing pipeline. Each detector type has dedicated readers that produce flat dicts consumed by the standard transform/collation/Point infrastructure.

LArTPC (JAXTPC production):

• LArTPCSegReader: 3D truth deposits from seg files
• LArTPCRespReader: sparse wire signals from resp files
• LArTPCLablReader: per-volume track_id->label lookup from labl files
• LArTPCCorrReader: 3D->2D correspondence from corr files (vectorized)
• Modality-driven coord ownership: seg->3D, corr+labl->2D labeled, resp->2D merged
• Both resp and corr available as separate point clouds (resp_coord, corr_coord)
• Volume filter for single-volume loading

Water Cherenkov (PMT-based):

• WCSegReader: 3D track segments from flat CSR format
• WCSensorReader: PMT response + per-particle sparse decomposition
• Output modes: response (per-sensor), labels (per-particle sparse), separate

Minimal changes to existing pimm code (3 files, 19 lines):

• index_valid_keys extended for LArTPC keys
• collate_fn skips _-prefixed metadata keys
• Dataset imports added

70 tests across both detector types verify all modality combinations, transform pipelines, collation, DataLoader workers, and toy model forward/backward passes.

[youngsm]

May be better to make the name of this specific data format less generic than "detector dataset"? Would be helpful to have a name for the dataset now, lol. Maybe call it a jaxtpc dataset? For now until we figure out the big name.

[OmarAlterkait]

So the idea here is to have this for both JAXTPC, LUCiD, ...
Hence why I named it a generic detector dataset, but I could be more specific and change the lartpc one to jaxtpc if you think that's better. But a dataset name would be convenient, I agree

[youngsm]

Yeah, that's understandable. But I think it would be a good idea to be more specific. We could try to persuade people to use this dataset format by naming this something like DefaultLArTPCDataset and throw it in datasets/defaults.py, but we shouldn't force it, if that makes sense.

The hope to me is that this repo will be usable with any already-made dataset anyone is bringing in without needing to remake it to fit this specific format. Instead, they would just be required that to make a dataset single object in a single file where the output of the dataloader is the same. I think this is slightly divergent from your instructions in the "adding a new detector" section of this doc.

[youngsm]

Again LArTPCDataset is too generic of a name I think.

[youngsm]

Same as comment above

[youngsm]

Oh, also if you're wanting to add unit tests (which is a great idea) can you make a folder called tests in the root dir and put them there?

[youngsm]

Thanks a lot for the changes.

One last thing... it would be amazing if you could add a doc string like below to the get_data methods for the jaxtpc and lucid datasets. Would be helpful for skimming purposes.

    def get_data(self, idx):
        """Load a point cloud from h5 file.
        
        Output dictionary:
        - coord: (N, 3) array of coordinates
        - energy: (N, 1) array of energies
        - momentum: (N, 1) array of particle momentum (v2 only)
        - vertex: (N, 3) array of vertices (v2 only)
        - segment_motif: (N, 1) array of motif labels
        - segment_pid: (N, 1) array of PID labels (v2 only)
        - instance_particle: (N, 1) array of particle instance labels
        - instance_interaction: (N, 1) array of interaction instance labels
        - segment_interaction: (N, 1) array of interaction labels
        """