Use byte encoded Lightning messages rather than json encoding

This specification could be improved by using byte encoding for Lightning messages instead of JSON encoded payloads. This would make the specification more precise, faster to parse and require less space to transmit and store messages. Current Lightning messages use byte encodings for this reason and all Lightning implementations implement codecs for handling byte encodings. Using an encoding format familiar to reviewers of current Lightning messages should also help increase feedback and facilitate eventual adoption.

This is a big change, but should help with the evolution and adoption of PeerSwap.

For example, the `swap_in_request` message as currently described looks like:

1. `type`: 42069
2. `payload` json encoded:

```
{
protocol_version: uint64,
swap_id: string,
asset: string,
network: string,
scid: string,
amount: uint64,
pubkey: string
}
```

An example of this message described with byte encoding based on the [fundamental Lightning types](https://github.com/lightning/bolts/blob/master/01-messaging.md#fundamental-types) might look something like the following:

1. type: 42069 (`swap_in_request`)
2. data:
* [`u16`:`protocol_version`]
* [`u32`:`swap_id`]
* [`chain_hash`:`network`]
* [`short_channel_id`:`short_channel_id`]
* [`u64`:`amount`]
* [`point`:`pubkey`]
* [`request_tlvs`:`tlvs`]

1. `tlv_stream`: `request_tlvs`
2. types:
1. type: 1 (`asset_id`)
2. data:
* [`...*byte`:`data`]

Note: `network` field indicates the `chain_hash` of the network used to create on-chain transactions, such as Bitcoin `mainnet` or `signet`, but could also indicate a network such as Liquid.

The optional `asset_id` contains any `network` specific data needed for on-chain transactions.