LSPS0: Consider introducing length prefix to allow including (optional) TLVs

[tnull]

Currently, the Lightning network message used by LSPS0 is a simple BOLT8 type|payload format for which payload spans the rest of the message, i.e., does not include a length prefix but is expected to be the raw JSON object in UTF-8 string encoding.

• For one, the spec isn't super expressive around this fact, we could consider clarifying that payload doesn't include a length prefix.
• In order to future-proof LSPS0, we could consider introducing a length header, which would allow implementations to add optional TLV fields to the message. Likewise, future iterations of the spec would be able to introduce additional fields on the BOLT8/Lightning level.

We should at least consider this before finalizing LSPS0.

[tnull]

FTR, @ZmnSCPxj-jr gave a 'mild NACK' in the Telegram channel. As nobody else seems to be interested in TLV-based extensibility and I'm not feeling super strongly about it, I'm going to close this.