Expose the read-only file API on embedded-filesystem builds

[meeloo]

rr_filelist answered {err:1} on a USE_EMBEDDED_FILES build, so DWC and AxisControl showed a broken file browser. The whole file API in HttpResponder is gated on HAS_MASS_STORAGE, which USE_EMBEDDED_FILES turns off - but EmbeddedFiles.cpp implements the very MassStorage functions those endpoints call (FileExists, DirectoryExists, FindFirst, FindNext). The capability was there; only the HTTP layer hid it.

fileinfo, filelist and files are now available when either backing store is present. upload, delete, move and mkdir stay mass-storage only, since an embedded filesystem is read-only. thumbnail also stays mass-storage only: it calls RepRap::GetFileFragment, which is not compiled for embedded builds.

Two things worth recording:

• the fallback for boards with neither store emitted {err:1}, which is not valid JSON. Clients report it as a parse error rather than as an error code. Now {"err":1}.
• adding a rejection branch for the write endpoints pushed GetJsonResponse past the range of a Thumb branch and the link failed with dangerous relocation. That function is close enough to the limit that it is worth knowing before adding anything to it. The write endpoints fall through to unknown-request handling instead.

Duet3_MB6HC is byte-for-byte the same size afterwards, so nothing changes on the mass-storage path.

Testing note: nothing upstream builds USE_EMBEDDED_FILES, so this cannot be exercised without a build config for the embedded variant. I have one at meeloo/RepRapFirmware:build/embedded-mb6hc-config and can open it as a separate PR, fold it into this one, or leave it out - whichever suits

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[meeloo]

I have read the Duet3D CLA v2.0 and I hereby sign it