Stop using file extensions to determine `GameInfo.System`

see also #2889

Detection can be a list of IFileTypeDetectors (something like Func<byte[], VSystemID>) run on the rom in order (for small roms, can run in parallel with one copy of the rom per thread). We have a bit of this already for disc images and ZX Spectrum / Apple II. edit: DiscIdentifier uses file extensions too -_-
For an example of what these detector classes might look like, see SatellaviewFileTypeDetector.
The ones which fail faster (e.g. magic bytes) should be run first.
Not sure what should happen if multiple match, maybe we'll need to manually deprioritise an implementor that's prone to false positives. I don't think the current system has anything like this as it uses file extensions—obviously mutually-exclusive.
We could allow the implementators to return a list of multiple file types (something like Func<byte[], VSystemID[]>) for polyglots.
Rather than system ID, we could use MIME types. On my Manjaro machine, I'm seeing most given unique types by file/mimetype: application/x-atari-2600-rom, application/x-fds-disk, application/x-gba-rom, application/x-n64-rom, application/x-pc-engine-rom, etc., notably home PCs seem to be a problem. I'm not suggesting we delegate file type detection to file (libmagic)—though we could. IANA is the authority for MIME types. (On a related note, we should look into binfmt_misc to make roms executable, with EmuHawk taking the role of a translation layer.)

also need to make MAMEMachineDB.IsMAMEMachine override opt-in

Start with RomLoader.cs, especially the MAMEMachineDB.IsMAMEMachine override, and compare the existing DiscIdentifier and SatellaviewFileTypeDetector implementations. Map how file extensions currently determine GameInfo.System, then define detector ordering and multiple-match behavior before replacing that path. Done means system detection no longer depends on extensions and the MAME override is opt-in.