Write-side parity: ExportImageToPhysFS / ExportWaveToPhysFS / ExportImageAsCodeToPhysFS

Summary

The current API has good coverage for loading raylib assets through PhysFS (LoadImageFromPhysFS, LoadWaveFromPhysFS, etc.) but only generic byte/text writers (SaveFileDataToPhysFS, SaveFileTextToPhysFS) on the write side. Add typed export wrappers so that screenshots, recorded audio, generated images, and user-generated content can all go through the PhysFS write directory without callers having to round-trip through raylib's stdio-based exporters.

Proposed API

bool ExportImageToPhysFS(Image image, const char* fileName);
bool ExportImageAsCodeToPhysFS(Image image, const char* fileName);
bool ExportWaveToPhysFS(Wave wave, const char* fileName);
bool ExportWaveAsCodeToPhysFS(Wave wave, const char* fileName);
bool ExportFontAsCodeToPhysFS(Font font, const char* fileName);  // if feasible

Each one would mirror its raylib counterpart but write through SaveFileDataToPhysFS instead of the OS filesystem, so the file lands in whatever directory was set via SetPhysFSWriteDirectory() (typically GetPrefDirectory()).

Why

• User screenshots, level editors, and save-game data should land in the pref directory by default — right now callers have to call ExportImageToMemory() and feed the buffer into SaveFileDataToPhysFS() manually.
• Keeps the read/write API symmetric, which is currently a small papercut.
• All of these are thin wrappers — raylib already provides the in-memory exporters.

Notes

• ExportImageToMemory() / ExportWaveAsCode() from raylib already produce the buffers; these helpers just plumb the bytes through PhysFS.

Start with the proposed ExportImageToPhysFS, ExportImageAsCodeToPhysFS, ExportWaveToPhysFS, ExportWaveAsCodeToPhysFS, and possibly ExportFontAsCodeToPhysFS entry points. Review ExportImageToMemory and ExportWaveAsCode alongside SaveFileDataToPhysFS and SetPhysFSWriteDirectory; done means the supported typed exporters write their generated buffers through the PhysFS write directory.