feat(metadata): add RAWG.io as a metadata source

[BlizzHacker]

RomM has twelve metadata handlers and RAWG isn't among them. This adds it.

What it's for, and what it isn't

RAWG is a large general-purpose games database with a generous free tier, which makes it a reasonable first source for anybody who hasn't yet obtained IGDB or MobyGames credentials.

Being straight about the limits, because I'd rather you judge it accurately than merge it on enthusiasm: RAWG is strongest on modern and PC titles and thinner on retro than IGDB, MobyGames or ScreenScraper. It is unlikely to beat any of them on the platforms most RomM users care about. It's offered as an additional source, not a replacement for anything, and it's disabled unless a key is set.

If you'd rather not carry a thirteenth handler for that value, closing this is a completely reasonable call and no follow-up is needed.

Shape

Follows the existing handler pattern:

• RAWG_API_KEY gates it; is_enabled() returns False without one
• (rawg-12345) filename tag pins a match by hand, same convention as moby- and hltb-
• get_matched_roms_by_name backs manual matching, unfiltered by similarity so the operator can choose
• Registered in handler/metadata/__init__.py as meta_rawg_handler

Two decisions worth flagging

Platforms are mapped only where RAWG actually has the platform. A good deal of the retro catalogue is simply absent there. Mapping those to a near neighbour returns a confident match for the wrong system, which is worse than returning nothing — so 44 platforms are mapped and anything else yields rawg_slug=None and the handler stays out of the way. I removed a c64 → commodore-amiga mapping from my own first draft for exactly this reason.

An unmapped platform returns the fallback rather than searching unfiltered. Searching every platform RAWG knows finds something for almost any title, and that something is frequently the wrong console's release.

401 and 404 are logged and return an empty result rather than raising, so a bad key or an unknown id lets the next handler in the chain try instead of failing the scan.

What I verified, and what I couldn't

Verified: the handler imports and runs correctly inside a real RomM instance (4.9.2 container) — platform mapping, case-insensitivity, the filename tag, and metadata extraction from a sparse response all behave. Every UniversalPlatformSlug member referenced was checked against base_handler.py programmatically; the first draft had three wrong names and one wrong platform mapping, all fixed.

Not verified: I could not run your pytest suite — the deps aren't in my environment and the production image doesn't ship pytest. The included tests are written to match test_igdb_handler.py's style but have not been executed. Please treat them as unrun until CI says otherwise.

Also untested against a live RAWG key, so the exact response-field mapping (description_raw, short_screenshots, released_timestamp) is from their published API docs rather than an observed payload. Happy to adjust once someone with a key runs it.

Docs

I haven't touched the docs site or .env.example — tell me where you'd like RAWG_API_KEY documented and I'll add it.

---

Offered as a gift from the Cartridge project. Thanks for RomM — your EmulatorJS core map is what our playability routing is built on, and it's credited as such.