Update the ISaveRam interface for clarity.

[SuuperW]

ISaveRam can no longer return null for SaveRam, which used to indicate that the current game has no SaveRam. Instead, cores conditionally provide the ISaveRam service. There is also a behavior change in the frontend, as it no longer silently modifies the .SaveRam file before passing it to the core. This could result in some previously-working saves not working anymore (bad dumps, perhaps?) but should not affect any .SaveRam files generated by EmuHawk.

Several cores have unusual implementations here and should be reviewed by someone who knows more of how they work:

• MSX and O2Hawk: It seems there are no writes to SaveRAM, ever. So they does not ever provide SRAM despite implementing the interface.
• mGBA: According to a code comment, the core does not know the SRAM size at startup. I have made it provide an empty byte array if it doesn't have one, instead of conditionally providing the service. mGBA does not know a game's save type (and as a result actual savedata size) on startup. Gambatte might be the same, Idk.
• MAME: Uses files? Service is registered in a callback.

Multiple other cores also use an API to get SRAM data/size from external code and so might also have mistakes. I've made them unregister the ISaveRam service if CloneSaveRam would return null at the end of the constructor.

My original implementation of this, that adds a property SupportsSaveRam to the ISaveRam interface instead of making cores conditionally provide the service, can be found in my sram branch.

Check if completed:

• I have run any relevant test suites
• I, the commit author, have read the licensing terms for contributors (last updated 2024-06-22) and am compliant