VFS buffers entire files in RAM — add streaming/seek-backed reads for large content

Summary

raylib_libretro_vfs_open() in include/raylib-libretro-vfs.h reads the entire file into memory on open (handle->data). For large content accessed through the VFS, this is costly — and VFS-aware cores compound it.

Impact

When a VFS-aware core loads a large CD image through the VFS bridge (e.g. a PlayStation .chd via PCSX-ReARMed built with USE_LIBRETRO_VFS):

• Our VFS open allocates the whole file in RAM.
• libchdr then calls chd_precache, allocating a second full-size copy.
• For a ~343 MB PS1 CHD that's roughly 700 MB resident for a single game.

Fine on desktop, but risky on the Web (Emscripten) and Android targets where memory is tighter.

Proposal

Replace the whole-file buffering with a seek-backed VFS that reads on demand from the underlying source (the real file handle, or the PhysFS handle for archived content) instead of materializing the full file. read/seek/size would map to the underlying fread/fseek/length (or PhysFS equivalents) against a kept-open handle.

Interim mitigation

If a full rewrite isn't desired yet, at minimum document the in-RAM cap near raylib_libretro_vfs_open() (the PhysFS platform shim already notes a related ~2 GB int size cap).

Notes

• Surfaced while fixing CHD-in-ZIP loading over the VFS bridge.
• The per-read byte-copy hot path was already optimized to a single memcpy; this issue is about memory footprint, not CPU.

Start in include/raylib-libretro-vfs.h at raylib_libretro_vfs_open() and inspect how handle->data is populated and used by the VFS read, seek, and size operations. Trace the real file and PhysFS handle paths, then define completion as on-demand reads without materializing the entire file, while preserving access to large CHD content through the VFS bridge.