Abstract file storage system for future expansion

[cmeyer]

This is a precursor to multiple storage enhancements including storing a project as a single HDF5 file, having multiple projects open simultaneously, remote projects, read-only projects (e.g. example data), threaded file writing and other performance improvements, etc.

Notes from 2022-12-11:

• There is no pure read-only project. All projects are writable. This is because user can always do processing and needs to store results.
• Projects have a container type (storage system) - index/folder; folder; zip file; HDF5 file; etc.
• Projects have one or more sources of data, which can be read-write or read-only. Data source may be internal (e.g. individual files within the project folder) or external (e.g. a reference to an HDF5 file stored outside the project).
• How are references to external sources stored? Perhaps import-only for now?
• System should support ability to separate storage of metadata from storage of data. For example, a non-nionswift HDF5 file may be read-only and contain multiple distinct data arrays. Additional metadata such as captioning, calibration, description of data layout, etc. can be stored within the project itself. This also implies that the user should have the ability to change the native description of the data layout (this is not currently possible).
• Source of data handling could be a plug-in. Should have either read-write or read-only.
• Merge projects. Internalize data.
• Web. HDF5. NetCDF. Panda tables.
• Storage handlers (file handlers) are handlers specific to the project container type (storage system) that allow for some customization of how data is stored within the container. Customization may include data size, layout, or other discriminators.

[cmeyer]

See commits around d50c23fc82adb5671748fe41b90fd0adbe53b7b5.