Improvements to ln spec message type definition

[vincenzopalazzo]

I didn't find the time to finish my prototype on the code generation for the ln spec message in https://github.com/lnspec-tools/lncodegen.rs, but when I saw this pull request (https://gist.github.com/HenningTimm/ab1e5c05867e9c528b38599693d70b35), I thought it was a good moment to bring up some more issues.

1. With our BOLT 1, it's not quite clear when and how certain types are used (for example, truncated vs untruncated integers).

2. We should provide more examples of how the Type-Length-Value (TLV) format works. At least one example should show how to serialize values to the TLV format and how to deserialize them back.

3. We can change our type definition from a custom format to JSON. In this way, the init method will look like this:

{
     "type":  16,
     "gflen": "u16" 
      ...
}

This approach will provide a standard format for flen*byte that may not be trivial for someone who is new to the project.

Regarding BOLTs being more related to the implementor, as well as the BOLT 1 type definition, I think there's an incentive to clarify these points in the spec.