Stop using file extensions to determine GameInfo.System

[YoshiRulz]

see also #969, #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 -_-
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, especially because it will be a pain to bundle it on Windows. IANA is the authority for MIME types.

also need to make MAMEMachineDB.IsMAMEMachine override opt-in

[CasualPokePlayer]

Note that these issues only apply if a match isn't found in the gamedb anyways (so bad dumps, hacks, homebrew, or systems where the gamedb is not available).

[YoshiRulz]

gamedb should be optional (#2939) and that still leaves polyglots unaccounted for