Loading large files without need_fullpath=true

[Alcaro]

Currently, a core can ask for either a filename, or a pointer to the data. This sounds quite limiting to me. Desirable features:

• We need the ability to pass in a simple filename, like now. Some cores don't work with anything else, and rewriting them is a significant task.
• Pass in a memory block which the core copies, like now.
• Pass in a memory block, which is not freed until the game is unloaded; this allows the frontend to mmap it (at least on some platforms). It also helps on systems where the ROM is a significant fraction of the system memory and two copies can't fit in RAM, like GBA on PSP.
• The core allocates a piece of memory, which the frontend loads the ROM to. Okay, we're unlikely to need both this and the above two, but which one to drop?
• Memory stream - the frontend hands out some kind of memory stream structure, and the core can then ask for parts of the loaded file. (Should the core or front allocate the needed buffer? When to free the memory? Should the core have access to the underlying base name, if one exists? Do we want to make them writable and move SRAM to there?)
• Some way to handle multiple files, for bsnes and Mednafen-PSX and a couple of other crazies. This is easy with filenames, but we need something for the other methods, or they'll be forced to fall back to filename.
• Make sure we pass in only one of the above methods, so we don't risk marking a core as not needing the path but then using it anyways. We actually had one of those a while ago.

Optional: BizHawk needs some parts of the disk I/O to be in the frontend. Try to figure out which parts and whether we can reasonably support it, or if their demands are too unrelated and/or crazy.

[Alcaro]

• We could probably drop filename support and reroute the fopen calls. Any sane core either uses the C or C++ standard libraries (which we can #define into something that ends up in libretro-sdk and reuse across most cores), or something behind a couple of #ifdef (where we can add a third branch; no sane person wants #ifdefs all over, so there is most likely a wrapper layer nearby already). I'm happier if cores don't access the file system at all. My front allows treating http://example.com/roms/snes/smw.sfc as a filename, it's downloaded and works fine; the more cores I can do that with, the better. Though there are most likely a pile of stupid cores and stupid potential cores floating around...
• We could drop the front-allocates-and-core-copies method, because it can be implemented with about five lines of code on top of core-allocates-front-fills-in. But on the other hand, the more changes from libretro v1 we require, the tougher the switch becomes... ...though there is no way to implement this without breaking it, so requiring another five lines of code to an area we're changing anyways is a neglible cost.