Move RetroCore instantiation to load_game for better ergonomics

[InquisitiveCoder]

First off, thanks for this crate! I was able to get a toy libretro core up and running in no time, even as a Rust newbie.

That said, having to return an instance of my core in the init method was unpleasant since it meant deferring initialization of some fields. Removing init and returning the core instance in the return value of load_game in my fork of libretro-rs streamlined my core's code.

To the best of my knowledge, anything that can be done in retro_init can also be done in retro_load_game. I'm relatively new to libretro development so it's possible I overlooked something, but I couldn't find any options in libretro.h for which that wasn't the case. I also found a comment in the libretro Discord server that confirms this: "I think the idea is that retro_init should do stuff relevant for all content, and front doesn't call deinit+init if it loads new content in same core, to save some time. Not sure if any cores actually do that and benefit from it in practice. It's perfectly fine to do everything in load_game.".

Moreover, it's not possible to report errors to the frontend until retro_load_game is called since retro_init lacks a return value. It's hard for me to imagine a situation where partially initializing a core in retro_init would provide a benefit over doing all of the initialization in retro_load_game. The same user quoted above also said: "retro_init returning void is also generally considered a mistake in hindsight. the standard recommendation is set a global variable that makes retro_load_game instafail." I'd go as far as to say there probably isn't a good reason to use retro_init even in C code due to this.

While this would be a breaking change to libretro-rs, I believe it'd make the crate easier to use for most (all?) users without any loss of generality. If you want, I can open a pull request with my changes.

[ghost]

Thanks for the suggestion! Sorry for the delay, I've only recently gotten back into working on this crate. Feel free to open a PR, and I'll see if it can be reconciled with the libretro documentation.

I am going to be migrating this repo over to GitLab and then mirroring it back as read-only in the near future, but I'll be sure to preserve any PRs/issues opened before that time.

[InquisitiveCoder]

No worries, I'm also working on this on and off. I pulled your latest commits and opened a PR as requested.

[ghost]

Closed by #4