This commit introduces a patch that hardcodes "libretro_info_path"
directly in the RetroArch code, without the issues of the previous
approach.
With this commit, RetroArch stops reading "libretro_info_path" from
`retroarch.cfg` file, and always use the default.
`retroArchCores` is strange: it requires a global configuration on nixpkgs, as:
```nix
nixpkgs.config.retroarch = {
enableDolphin = true;
enableMGBA = true;
enableMAME = true;
};
```
To do so, we ended up declaring all available emulators on
`all-packages.nix`. Failing to do so would mean that the emulator
wouldn't be available.
However, there is a mechanism on nixpkgs that also works: overrides.
Overrides are similar on how other packages works, for example:
```nix
(retroarch.override { cores = with libretro; [ citra snes9x ]; });
```
So let's remove `retroArchCores` and leave the overrides mechanism
instead.
The issue of non-working cores on newer versions of RetroArch was caused
by the missing core metadata that is available on
libretro/libretro-super repo. This also allows RetroArch to works
properly, for example there is no need to load a core before loading a
content: RetroArch knows each emulator to load depending on the
available emulators and the file extension.
To load the metadata from `/nix/store`, we need to patch the
`retroarch.cfg`. Sadly this file is only updated when needed, for
example, it will update if the path that it is pointing doesn't exist
anymore. However, before this PR it pointed to a file located in the
HOME directory, so if someone used RetroArch before they will probably
have issues while loading the file.
I tried to patch the configuration loader directly but the code is kinda
messy and this seems very prone to breakage (while the `retroarch.cfg`
file seems an stable interface). One better solution will probably be
the introduction of a module that can generate `retroarch.cfg` file
(since retroarch supports loading a config from `/etc/retroarch.cfg`).
But this will come in a future PR.
From retroarch 1.9.3 and above, it stops loading the cores.
This probably can be fixed, but for now at least this brings the
retroarch to a newer (working) version.
