lnwire: start to write the type byte when encoding channel updates in failures

[Roasbeef]

Initial implementations were somewhat split after a spec ambiguity, so we made a change to be able to read both versions (with and w/o the type byte).

A new spec PR proposes the we just write the type byte after all: lightning/bolts#979

On our end, we can start to write the type byte in the next version without worry that we're borking communication to older versions, since we're already able to read both versions. We can opt to use the generalized lnwire.WriteMessage function (which'll add that type byte), or we can just write 0x0102 (the channel update message type) before we encode an onion error.

[morehouse]

I just encountered this issue while fuzzing.

The fuzzer generated an onion failure containing a channel update that begins with 0x01020102. When decoding the onion failure, the first 0x0102 gets stripped, then when re-encoding the 0x0102 doesn't get added back. Thus when we decode again, we get a different channel update.

Seems like a rare corner case that doesn't matter in practice. But it would be nice to fix it so my new fuzz tests stop failing.

I'll send a PR shortly.