MAME since 0.225 have a fix for the build issues while building in
parallel. Since libretro.mame is on 0.227 right now, should be safe to
enable.
Since eventually enableParallelBuilding should be the default, enabling
it for all cores except the older MAMEs seems better than just enabling
for libretro.mame.
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.
