Add functonality to return a 'file object' for data associated with photoscans/volumes/transducers

Currentlly for photoscans, the loading of vtkPolyData and vtkImage data is handled in openlifu. However, for loading model files and volume files associated with transducers and volumes, SlicerOpenLIFU uses get_transducer_absolute_filepath_info and get_volume_info. While this works for now, these functions will likely go away if the database is represented differently in the future. For example what if the data were stored online and the way to get it is not an absolute filepath but rather a URL that needs to be sent to a download utility.

Once approach for transducers is to generalize the code for loading models out of photoscan.py and create a util function in openlifu that returns vtkPolydata for each model included in the transducer file.

In general, openlifu should be responsible for getting the data in the first place. Maybe openlifu should be responsible for providing a kind of "file object" that hasn't necessarily been read yet. fsspec seems to have exactly such a generic concept of "file object" that we could use. (It seems it's one of the tools DVC uses under the hood!)

Start with photoscan.py and the existing get_transducer_absolute_filepath_info and get_volume_info usage described in SlicerOpenLIFU. Compare how model and volume data are obtained, then define the file-object boundary for current local data and future URL-backed data. Done means openlifu owns acquisition for photoscans, transducers, and volumes without callers relying on absolute paths.