SDL_MemoryMapFile implementation

[kieselsteini]

This PR will introduce the new SDL_MemoryMapFile API to provide a simple cross-platform way, to create read only file mappings in memory.

Description

In order to make it work on all platforms we have to introduce a platform specific struct called SDL_MemoryMappedFile which holds platform specific details for the file mapping.

// create a new memory mapped file (beginning at offset)
SDL_MemoryMappedFile* SDL_MemoryMapFile(const char *file, size_t offset)

// unmap a previously created memory mapped file
bool SDL_UnmapMemoryFile(SDL_MemoryMappedFile *mmfile);

// access the data of the file (if datasize != NULL we store the size in here)
void *SDL_GetMemoryMappedData(const SDL_MemoryMappedFile *mmfile, size_t *datasize);

Existing Issue(s)

• only tested on my M1 Mac right now
• Windows code is just created using documentation, not even tried to compile it :(
• Windows code only works with 32-bit filesizes right now
• Windows implementation won't return any error on SDL_UnmapMemoryFile

[nfries88]

I would expect something that maps subrange of the file, like void* SDL_MapFileRange(const char* fname, size_t offset, size_t length) and maybe a convenience void* SDL_MapFile(const char* fname, size_t* length); that maps the entire file.

as I said in the proposal thread, having a writable mapping can also sometimes be useful. To support this the interface could reasonably take a subset of the same file opening options that the iostreams do for consistency's sake (the only one that doesn't really make sense here is append, although it could be reused to mean "allocate" here - as in performing the equivalent of fallocate before the mmap if the requested mapping passes the end of the existing file)

[madebr]

Can we implement memory mapping on top of SDL_IOStream? Would truncating files be useful to allow mmap'ing an empty file?

@kieselsteini About windows, I often develop using a mingw toolchain on Linux, and test using wine. I think brew provides one (mingw-w64)