Allow for loading assets that are inside of a ZIP folder

[ethereumdegen]

What problem does this solve or what need does it fill?

For my game, I want to distribute the assets in a ZIP file (similar to a Doom WAD file) for increased modding capabilities. Minecraft allows for this as well.

What solution would you like?

I propose that bevy_asset/src/loader.rs LoadContext{} add a function that allows for loading assets with a Reader instead of only with a String.
Furthermore, I suggest that the assets resource and assets_server resource also allow for loading assets with a Reader instead of only with a String.

This will require a cascade of changes, since now loaded assets may or may not have a path. The way I see it, on LoadContext struct, asset_path should be an Option. This is because any assets that are loaded from a Reader will simply not have an asset_path. While this would mean that assets that are loaded via Reader could not be reloaded from HotReloading, it actually >could< still be possible to have hot-reloading work (with some R&D) because the zip file itself could be hot reloaded of course.

What alternative(s) have you considered?

Alternatively, virtual filesystem path could be used for a zip file, so a 'fake made up' string protocol can be made up to represent a file that is inside of a zip file. This is common for other engines.

Additional context

Here is a gist of me writing a loader to load files from a zip -- it doesnt work because i can only load assets via a string path and i cant specify a reader https://gist.github.com/ethereumdegen/f028b1072f8d91ccd8972bf846b4e189

[ethereumdegen]

found a soln by wrapping my ZipRead struct into a futures cursor and then doing this on the reader

         let gltf_loader= 
         GltfLoader {
                supported_compressed_formats: CompressedImageFormats::all(),
                custom_vertex_attributes: HashMap::new(),
            };

            gltf_loader.load( futures::io::Cursor( reader_of_zip_file))