[Feature] Normalize HTML in scraped ROM summaries instead of storing the tags as plain text

Is your feature request related to a problem? Please describe.

Split out from #4568, which was closed as a duplicate of #4072. The linebreak/rendering half of that report is tracked in #4072; this issue covers the other half, which is a separate concern.

Some metadata providers return summaries/descriptions containing HTML markup. RomM stores and displays whatever the provider returns verbatim, so those tags end up rendered as literal text in the game summary, and users have to clean them up by hand.

Quoting the original report in #4568:

some metadata sources support html formatting, and when pulled by RomM will import the html tags as plain text. This can make such metadata difficult to read and require manual cleanup.

Describe the solution you'd like

Normalize provider summaries at scrape time, in the metadata handlers, so what lands in the DB is clean text. Today the only normalization anywhere in backend/handler/metadata/ is a single html.unescape() on the ScreenScraper summary (ss_handler.py); no handler strips tags.

Options, roughly in order of increasing scope:

1. Strip tags (converting the block-level ones to newlines so paragraph structure survives) and unescape entities, in a shared helper used by every handler that sets summary.
2. Convert the HTML to Markdown, which pairs with #4072 if the summary ends up being rendered as Markdown.
3. Render the HTML in the UI. Riskier, and it would still leave the stored value provider-specific.

Describe alternatives you've considered

Doing nothing and letting users clean up summaries manually, which is the status quo.

Naively dropping anything between angle brackets. As the original reporter noted, a summary can legitimately contain angle brackets as plain text, so this should go through a real parser rather than a regex.

Additional context

Where provider summaries are set today: backend/handler/metadata/ (igdb_handler.py, moby_handler.py, ss_handler.py, flashpoint_handler.py, steam_handler.py, hasheous_handler.py, and others).

Worth deciding alongside #4072, since the choice of what to store depends on how the summary is rendered.