TRI-27 emulator: the CONSTANTS section parser reads the section id as the constant count

[dmitrii-f-t27]

Where: loader.zig at 976df51.

What happens.

• The CONSTANTS parser reads the section id (2) as the constant count and skips sixteen bytes.
• The documented layout (id, count, count × 8 bytes) is therefore misread.
• With one constant, the loader lands nine bytes into the code that follows.

Source: specs/isa/tri27_bytecode.t27, FINDINGS and CONSTANTS_LAYOUT (line 42).

Expected. The parser reads the id, then the count, then count × 8 bytes, as documented.

Vectors. Both are in conformance/trinity/tri27_programs.json:

• load-constants-and-bss: the id byte is read as the count 2;
• load-constants-documented-layout: a section written as the documents say is misread.

Found while writing the S05 specs of #988 (gHashTag/t27#3581); until now it lived only in the spec's FINDINGS. The vectors are replayed by tools/trinity_tri27.py in gHashTag/t27. Tracked in #1164.