Refactor CARD FileIO with on-demand handles

[Irastris]

Refactors CARD FileIO to only have a handle open on the RAW save when actually in use.

Among other benefits, this prevents Windows (and presumably other OSes) from blocking you from making copies of the RAW save while a port utilizing Aurora is running, which can be irritating during development.

[Antidote]

While I'm not opposed to this, I'm concerned that this could cause potential race conditions with the file system driver. Does SDL guarantee a flush when the stream is closed? Or does it defer that?

To clarify, I'm not so much concerned that aurora will get invalid data, I'm concerned that the user might accidentally copy the raw file while the stream is mid-write and get an incomplete/outdated file.

[Irastris]

Added SDL_FlushIO to paths to the FileIO constructor and fileWrite(), it believe it would be unnecessary for fileRead but let me know what you think

[Antidote]

Added SDL_FlushIO to paths to the FileIO constructor and fileWrite(), it believe it would be unnecessary for fileRead but let me know what you think

Yeah, it's unnecessary for read, flushing is only relevant for write.

[PJB3005]

Would it not be better to just set FILE_SHARE_WRITE?

[Antidote]

I don't see why we need to maintain a handle to a file that's only going to be periodically read and written to begin with.

[Irastris]

I'm also just not sure how that'd be done with SDL. Isn't FILE_SHARE_WRITE a Win32 API specific thing?

[PJB3005]

I don't see why we need to maintain a handle to a file that's only going to be periodically read and written to begin with.

So that there is no potential for the write to fail due to another program having a handle open.

[Antidote]

I'm also just not sure how that'd be done with SDL. Isn't FILE_SHARE_WRITE a Win32 API specific thing?

It is, lets avoid non-portable code where possible, I'd rather not have ifdef'd per platform code where it's not needed, SDL is perfectly adequate for what we're doing.

[Antidote]

I don't see why we need to maintain a handle to a file that's only going to be periodically read and written to begin with.

So that there is no potential for the write to fail due to another program having a handle open.

1. Games keep changes memory resident by design anyway,

2. We'd catch any failed write and return an error that would trigger a re-attempt in well formed code.

3. Using platform specific primitives is not helpful here.

4. I'd also prefer the write to fail if another application has a handle to it rather than silently corrupt. Having shared write enabled can cause that. The windows FS situation is a trainwreck.