Save Ram flushing might be all messed up

in a nutshell: CloneSaveRam() is meant to clear a dirty flag. but no user of CloneSaveRam() ever expects that to be destructive. CloneSaveRam() was intended as a promise that it would be flushed.

As one example, MelonDS internally in c++ (bizhawk shims files) clears a dirty flag when the saveram is gotten. I'm sure Suuper copied this from some other cores.

The whole API needs to be reworked, but I dont have an opinion on how.

It's possible we can smooth over some problems for now by simply removing every "is dirty" check related to automatic flushing, and mitigate some issues (see #2156; waiting for exact repro steps tho)

And don't forget, some cores can't sensibly track dirtiness at all (8bit and 16bit games too are commonly using battery save area as scratch memory too and dirtying it constantly).

Of course I would be remiss if I didn't point out, I dont like the idea of automatic flushing at all. But it should work.

see also #1466