v0.49.0

What it says the octets are will write them again

There were two walks over a machine text and both of them checked the same
thing: that the narrator stops where the text stops. That is a claim about
lengths. It is not a claim about names, and a narrator that said add where
the encoder wrote sub would have passed every one of them, on all three
machines, for as long as anyone cared to look.

Now the narration hands its fields back. Every instruction comes with the
way to write it again; the fields taken apart go to the encoder that put them
together; a label goes at every address anything branches to, and the whole
text is written a second time out of what the file says it is. Identical, or
one of the two has a field wrong and the place they stop matching says which.

221 programs on three machines, no disagreement, and 3849 octets of it in the
battery on every run.

Getting there wanted one packing site per shape of word, which the encoders
did not quite have: the wide-immediate sequences built their words inline, so
a movz and a lui had no address a caller could reach. And the x86 narrator's
operands are the encoder's own operands now rather than strings, so the name
and the re-encoding come out of one decode instead of two. Two names it had
wrong fell straight out of that: a mov that writes the low half is not the
mov that writes all of it, and a subs into the zero register is a compare.

Full Changelog: v0.48.0...v0.49.0

LOC: 24586