libretro: expose the standalone build's settings as core options

[WizzardSK]

The core advertised exactly one option, blastem_system_type. Everything else the standalone build lets a user change - the model, the region, RAM fill, the clock divider, every audio gain - lives in the same config tree the emulation code reads while it builds a machine, and nothing was writing to it. This adds the rest of what the standalone's settings menus offer and the emulator actually reads.

System: Mega Drive model, Master System model, default region, force region, initial RAM value, 68000 clock divider, MegaWiFi.
Input: port 1 and port 2 device.
Audio: overall / FM / PSG / RF5C164 / CD audio gain, FM DAC, low pass cutoff.
Video: overscan cropped at each edge, with auto keeping the frontend's own crop overscan setting.

Advertised through SET_CORE_OPTIONS_V2 with categories, falling back to the original flat variables when the frontend predates it. Every default is the value the core already behaved as, so a fresh config changes nothing: same geometry, same timing, and a 60 frame run of Sonic 1 produces an audio peak of 435 before and after.

Left out on purpose: window size, shaders, scaling, vsync, audio device rate and buffer size, key bindings, sync source, save paths, the file picker - a libretro frontend owns all of those. BIOS paths are settings too, but a core takes them from the system directory instead of asking; the TMSS ROM now joins the ones already handled that way, since without it a model with TMSS could not be used at all.

Two things turned up while matching the standalone's menus against what the code reads:

• The model lists need systems.cfg, which a libretro core has no copy of. get_systems_config() was returning nothing, so get_model() returned nothing and every model property - TMSS, VSRAM size, which FM chip, TAS behaviour - silently fell back to its built-in default. It is compiled into the core now, the same way rom.db already is. Defaults are picked to preserve exactly that fallback behaviour: md1va3 for Mega Drive, and a real Master System for Master System software rather than the standalone's md1va3, which would put it on the Mega Drive VDP.
• audio.cdd_gain is a dead setting. The standalone's CD audio slider writes it, but set_audio_config() reads audio.cdda_gain, so moving that slider does nothing. The option here is spelled the way the emulator reads it. Worth fixing in the nuklear UI too, though that is upstream's code and not this PR.

Gains, the FM DAC and the port devices are re-read while a game runs, through the same config_updated hook the standalone uses when its settings change, so they take effect immediately. The model, region, RAM fill and clock divider are only read while a machine is built and wait for the next load.

The controller port options offer the pad types the input glue can actually drive - 6-button, 3-button, none. The standalone's list also has multitaps, mice and keyboards, which need more ports and device handling than process_events() implements today.

Testing. With a small libretro host that prints what a core advertises and answers GET_VARIABLE from the environment: the v2 list and the v0 fallback both come out as intended, with the model lists built from systems.cfg and the defaults first. Then, checking that the values actually reach the emulator rather than just being advertised - region E with force on turns 320x224 at 59.92 fps into 320x240 at 49.70, model md2va1 fails the load with "Configured to use a model with TMSS, but failed to load the TMSS ROM from .../tmss.md" (the model reached genesis.c, the path reached the system directory, and the failure unwinds cleanly instead of taking the frontend with it), overscan options change the frame the core hands over to 331x243, and -24 dB of gain takes the audio peak from 435 to 27, which is the factor of 0.063 that asks for. Master System model choices are advertised but untested for want of a Master System ROM here.

[hunterk]

ditto for this one