Auto-generate preferred cores from source

[Morilli]

• closes Preferred core picker is intransparent and inflexible #3960

RFC.

This auto-generates the UI options for the core preferences picker from the list of available cores. This also requires changing the core attribute for many cores to signal that they are the preferred core for a specific system.
Basically, instead of having the core preference list stored entangled with the UI picker data and having to be manually maintained, the list is now based purely on the available cores.

This and the added tests ensure that all system ids with multiple core choices have an entry in the core picker (preventing mistakes like what d74b130 fixed) and that the default preference is always known, even when the user has configured a different preferred core for a given system id.

This will also make it impossible for fa08002 to occur, where quick(er)nes was both the preferred core and had lower than default priority. In reality this doesn't really show itself, but it's best to fix it nonetheless.

[YoshiRulz]

So this makes CoreConstructor.Priority the single-source-of-truth? I like a SSoT but I think we should remove the priority system completely.

[Morilli]

So this makes CoreConstructor.Priority the single-source-of-truth?

Yes, effectively. I'm myself not 100% sold on it, but it felt better than the current system at least. If we can get something set up that enforces that all systems that have multiple cores emulating it also have a preference choice in the UI, that would probably be enough already.

I think we should remove the priority system completely.

Oh? So just have preferences set manually and don't allow cores to alter their own priority?

[YoshiRulz]

Yeah, either in Config or CoreInventory.

I'm concerned about the no reflection case (#3768) and the case of adding cores at runtime (obviously with reflection) but mainly the former.