Handle game configuration more dynamically

Start by reading the per-game classes in VisualPinball.Engine.PinMAME/Games and the registration and dropdown logic around line 65 of VisualPinball.Engine.PinMAME.Unity/Editor/PinMameGamelogicEngineInspector.cs. Done means both the non-Unity solution and Unity package can load JSON game data with inheritance, support the listed metadata and mappings, and provide searchable game selection.

Right now, for every game, we create a class here and register them here. This is sub-optimal, because this configuration needs to be compiled, and it sits outside of Unity, so it needs to be compiled manually on every change.

A better approach would be to serialize the data as JSON and add the possibility to load them from anywhere. Since at some point there will be many games, the existing drop-down should be replaced by a more user-friendly search field.

The data should be the following:

• Metadata about the game
  • Name
  • ID (short name, but unique)
  • Year
  • Manufacturer
  • IPDB Number
• Available ROMs
  • ROM ID (name of the zip file of the ROM)
  • Version (readable name of the ROM)
  • Description (optional notes)
• Aliases (common items that we globally identify by name)
• Switches
• Lamps
• Coils

Depending on the game's system, some configurations are identical across multiple games. Thus, there should be a way of inheriting data, where a config can extend another, overriding existing values.

We need to be smart about how to set this up. The long-term goal is that if a table author works on a game that hasn't got a configuration yet, it can be easily created in the editor, and at some point submitted back to the repository for other authors to use.

Note that this issue applies to both the non-Unity .sln solution as well as the Unity-specific package.