Documentation: how to use neuroconv to load 50+ formats

[h-mayorquin]

This PR adds a new "Loading from other formats with NeuroConv" section to the IO documentation, showing how users can load data from any of the dozens of formats supported by NeuroConv directly into pynapple without writing an intermediate NWB file to disk. Each NeuroConv interface exposes a create_nwbfile() method that returns an in-memory pynwb.NWBFile, which can be passed straight to nap.NWBFile(). The docs include a code example, links to the conversion gallery, and a note on lazy loading behavior. To make this work with current NeuroConv releases, a temporary _DataChunkIteratorWrapper shim is added to interface_nwb.py that gives HDMF's DataChunkIterator the array-like protocol pynapple expects (shape, ndim, __len__, __getitem__) while preserving lazy loading. This shim will be removed once catalystneuro/neuroconv#1673 is released, after which the iterators will expose these attributes natively.

Compared to #503 which adds direct Neo support, this approach covers most of the same extracellular electrophysiology formats, particularly the most popular ones (SpikeGLX, Neuralynx, Blackrock, OpenEphys, Intan, Plexon, Axon), but also extends to optical physiology formats (Suite2p, Caiman, ScanImage, Inscopix, Miniscope), pose estimation (DeepLabCut, SLEAP, LightningPose), and other behavioral formats (video, audio, FicTrac) that are not present in Neo. This should be easier to maintain as it costs pynapple nothing: NeuroConv already builds a pipeline from Neo through SpikeInterface and handles the NWB conversion, so pynapple gets all of that for free by supporting in-memory NWB files (which it already does). That said, having two ways of supporting the same electrophysiology formats might still be a good idea since a direct Neo path avoids the NWB intermediate entirely. I would like to hear your thoughts.

As we work with NWB, we are interested in making it work as an interoperable format to translate between tools and formats. I think this is an excellent showcase of that capability: NWB provides an easy way for maintainers of downstream tools to offer broad format support by only supporting NWB (which in the case of pynapple is already central).

cc @bendichter

[gviejo]

Hi Heberto, thanks for the PR. As you noticed we are currently working on merging a python-neo support for pynapple. Yet I am not against having different ways of doing the same thing especially if it cost nothing for pynapple.
Would you be ok to have this PR merged first and then revisit this PR to merge the documentation part only?

[h-mayorquin]

Yes, that's OK, let's close this. I discussed today with @bendichter and we believe there is a better way of doing this.