Centralize and expand spoiler handling

[Hyperseeker]

Overview

This PR refactors spoiler handling. Specifically, it does the following:

• centralizes all spoiler IDs in a single location (spoilers.ts), providing an easy way to extend the system in the future
• moves the <Spoiler /> component from Monster.svelte (where the check had one hardcoded ID) up to Thing.svelte, and uses the centralized spoiler check to hide the thing when the check returns true
• updates location loot display to use location IDs from the spoiler file

The overall impact of this PR is: it allows for cleaner, unified handling of all spoiler items. (The one exception to that is location loot, as I didn't want to mess with systems I don't understand too much. It should, in theory, be possible to migrate this to the ID-based spoiler check, but I haven't looked into it, as it was out of scope for this PR.)

Related issues

Closes #214

Testing

Ran the dev server locally, searched a few things using default parameters (latest experimental, ASCII tileset, English language). Did not run the tests because they would take 10+ mins per, and I believe the manual testing (see below) should suffice.

Prefix-based hiding

Default (no `?hideNothing`): "No results."

With `?hideNothing`: all black glass items shown

ID-based hiding

Default: "No results."

With `?hideNothing`: ancient red dragon

Suffix-based hiding

(The suffix check is more of a futureproofing than an immediate need. I had to use the full item ID to check it because `_vitrified` is a catch-all for the current black-glass items.)

Default: "No results."

With `?hideNothing`: tree of glass apples

Items that shouldn't be hidden

Default: all relevant items shown

With `?hideNothing`: all relevant items still shown

Locations to hide loot from

Location itself (`mil_base`) is accessible in search

Loot from location (checked `9mmP`) does not appear on the list (hard to showcase since the viewport would not include the search menu no matter how hard I tried)

[nornagon]

const SPOILER_PATTERNS = [
  /^(f_vitrified_|f_glassedbody_|...)|_vitrified$/,
  /^mon_dragon_dummy$/,
];

[Hyperseeker]

While I agree that it's cleaner, I don't think it's better per se. Splitting them into named constants means they are easier to maintain for someone who perhaps isn't familiar with handling RegEx. Basically, the less cognitive load contributors have to go through to update the list, the less maintainance you will have to do later.