Encoding decoder tests don't test codepoints

[ChALkeR]

E.g. new TextDecoder('shift-jis').decode(Uint8Array.of(0x5C)) is \, not ¥ per spec and in all major browsers.
But test data has <span data-cp="A5" data-bytes="5C">

The mismatch is also noticeable in the test runner, on the very second row -- symbols are different + assert shows not a ¥ sign:

Also e.g. new TextDecoder('iso-2022-jp').decode(Uint8Array.of(0x1B, 0x24, 0x42, 0x21, 0x5D, 0x1B, 0x28, 0x42)).codePointAt().toString(16) is ff0d and not 2212 as in tests:

wpt/encoding/legacy-mb-japanese/iso-2022-jp/iso2022jp_chars.html

Line 177 in 4f21b11

<span data-cp="2212" data-bytes="1B 24 42 21 5D 1B 28 42">�$B!]�(B</span>

Those don't cause failures because the test runner doesn't test bytes -> charcode decoding.
What it tests here is that html decoding of bytes matches decoder decoding of the same bytes, but nothing compares them to the codepoint in the test data:

wpt/encoding/resources/decode-common.js

Lines 32 to 35 in 2a1fdfa

	assert_equals(
	nodes[i].textContent,
	decoder(nodes[i].dataset.bytes)
	);

(cc @domenic?)

[ChALkeR]

[
escape(new TextDecoder('euc-jp').decode(Uint8Array.of(0x5c))), // mislabeled
escape(new TextDecoder('euc-jp').decode(Uint8Array.of(0x7e))), // mislabeled
escape(new TextDecoder('euc-jp').decode(Uint8Array.of(0xa1, 0xdd))), // mislabeled
escape(new TextDecoder('shift_jis').decode(Uint8Array.of(0x5c))), // mislabeled
escape(new TextDecoder('shift_jis').decode(Uint8Array.of(0x7e))), // mislabeled
escape(new TextDecoder('shift_jis').decode(Uint8Array.of(0x81, 0x7c))), // mislabeled
escape(new TextDecoder('iso-2022-jp').decode(Uint8Array.of(0x1b, 0x28, 0x4a, 0x5c, 0x1b, 0x28, 0x42))), // labeled correctly
escape(new TextDecoder('iso-2022-jp').decode(Uint8Array.of(0x1b, 0x28, 0x4a, 0x7e, 0x1b, 0x28, 0x42))), // labeled correctly
escape(new TextDecoder('iso-2022-jp').decode(Uint8Array.of(0x1b, 0x24, 0x42, 0x21, 0x5d, 0x1b, 0x28, 0x42))), // mislabeled
]

Results in ['%5C', '%7E', '%uFF0D', '%5C', '%7E', '%uFF0D', '%A5', '%u203E', '%uFF0D']

They are labeled as A5 203E 2212 in all those encodings test data