SI refactorings

I looked a little bit into how you manage save chips content and I think you should be able to reduce easily the gap with upstream by doing the following :

• move the "saved_memory" struct (both definition and implementation) in your libretro.c file
• connect the saved_memory members with si.eeprom.data*, si.controllers[k].mempak.data, pi.flashram.data and pi.sram.data accordingly. This is done in main.c in m64p, but you can do anywhere before starting emulation.
• I didn't find how you effectively save the saved_memory content to disk. I guess this is handled inside retroarch, and cores just return a pointer + size so that can be done externally. So, just provide a dummy "save" callback and connect it to {eeprom,sram,mempak,flashram}.save.
• m64p allow only a single pointer of consecutive memory for eeprom content, whereas you need 2
  (eeprom,eeprom2). If you want to adhere to the m64p way without changing your data layout, you can :

option1: use a memory mapping trick in order to map eeprom and eeprom2 consecutively and provide that virtual pointer to eeprom.data. The mmap trick consists in allocating 2 consecutive pages such that the end of the 1st page correspond to eeprom1 and the beginning of the 2nd page correspond to eeprom2.

option2: allocate a contiguous buffer for eeprom, pass that pointer to m64p eeprom.data and do copies between that buffer and your saved_memory.eeprom{,2}. You can do the initial copy (saved_memory -> new_eeprom_buff) before emulation start. And keep saved_memory synchronized (new_eeprom_buff -> saved_memory) using the new "save" callback mecanism.

option3: not adhere to m64p for eeprom, and be free to manage that the way you want.

It's up to you to choose what you want for your fork. I'm just proposing options that I think could help.
(in my opinion, option 1 is the way to go if you can manage the extra complexity of mmap. option 2 is meh because of the extra synchronization needed. option 3 is simple and effective, but you have to maintain things on your own).

edit: you should also move format_saved_memory to libretro.c. And eventually use the format_* functions provided by the core.

Start in libretro.c and trace saved_memory and format_saved_memory, then compare the relevant setup in main.c from m64p. Review how eeprom, sram, mempak, and flashram expose their data and save callbacks. Done means the chosen EEPROM approach and save wiring are implemented without losing the existing saved-memory behavior.