Convert latin1 VStream text to UTF-8 before JSON encoding

[dtest]

latin1 characters become mangled when converting to utf8 in airbyte. This conversion is aimed to fix that.

[lizztheblizz]

Plain latin1 text comes through correctly now, nice. Two cases are still wrong, and one of them regresses incremental syncs compared to main. Exact fixes are inline. With them applied the full suite passes, and the new tests fail on the current head in exactly the two places below.

I reproduced this end to end with a real VStream from a local vttestserver (MySQL 8.0), through the copy phase and then a binlog-phase insert, and confirmed the _bin typing on MySQL 8.4.11 too:

column	phase	main	this PR
varchar latin1_swedish_ci	both	S�o Paulo ���	São Paulo €‘’
char/varchar/text latin1_bin	both	Kak�	Kak�
enum/set latin1	copy	Bras�lia	Brasília
enum/set latin1	binlog	Brasília	Brasília

1. Binlog ENUM/SET values get double-encoded. Since Vitess v21, vstreamer maps binlog ENUM/SET ordinals to labels taken from information_schema.columns.column_type (buildEnumStringValue), so they arrive as UTF-8 while Field.Charset still says latin1. The copy phase sends raw latin1 bytes (set names 'binary' in rowstreamer). Converting both breaks values that main gets right, and a full refresh and an incremental sync emit different strings for the same row.
2. latin1_bin columns are skipped. MySQL sets BINARY_FLAG on _bin collations and sqltypes maps that to BINARY/VARBINARY/BLOB, with Charset still 47. isTextColumn filters them out. Real binary columns are charset 63, which isn't in latin1Collations, so gating on the collation alone is enough.

Not blocking, but worth deciding before merge:

• UTF-8 bytes stored in latin1 columns (an app writing UTF-8 through a latin1 connection) used to pass through as São and now come out as São. That's exactly what MySQL returns to a utf8mb4 client, so I think the PR is right, but it's a visible change for anyone with legacy data like that.
• Already-synced rows don't heal. The U+FFFD substitution is lossy, so affected streams need a full refresh once this ships. Both points are worth a line in the release notes.
• Optional: vitess v0.17.6 already has charset.Convert plus a collation lookup. For latin1 it's byte-identical to decodeWindows1252 on collations 5/8/15/47/48/49/94, and it also covers latin2/cp1250/cp1251. Collation 31 (latin1_german2_ci) is missing from v0.17.6's table, so it would need a fallback. Fine to keep the hand-rolled table.

The cp1252 table matches MySQL's latin1 for all 32 bytes in 0x80-0x9F.