fix: support the WMF device ANSI code page

[KanJieTeam]

WMF text with ANSI_CHARSET or DEFAULT_CHARSET is currently decoded as Windows-1252. The same WMF can contain different text when Windows replays it on a device with another ANSI code page. LOGFONT face names also use that device code page, independently of the font's text charset.

Add the optional wmfAnsiCodePage playback setting. It defaults to 1252 and accepts known code pages; callers can supply the source device's GetACP() value. Explicit text charsets, Symbol text and EMF text keep their existing decoding. Preserve byte advances after multibyte decoding, including UTF-8 BOMs, and decode bounded ANSI font names with the same device setting. The converter does not infer an encoding from file bytes or browser language.

Validation: all 6,800 tests across 202 files passed, plus type checking, package builds and the browser-package check. Synthetic WMF tests cover both default charsets, explicit charsets, font names, byte advances, SaveDC/RestoreDC and malformed input. Independent Windows MultiByteToWideChar, CreateFontIndirectA/GetObjectW and text-extent checks confirmed the code-page behavior. No private documents are included.

[ChristopherVR]

Thanks for this — clean implementation, good test coverage (default charsets, explicit charsets, font names, byte advances, RestoreDC), and the 1252 fallback keeps existing behaviour intact. Merged.