Extended query messages are allow peers to exchange short channel id and timestamps, and
to query either announcement + updates or just updates:

- query_channel_range_ex is used asked to ask for a list of (short channel ids + timestamp)
- reply_channel_range_ex will return a list of (short channel ids + timestamp)
- query_short_channel_ids_ex is used to ask for channel updates and optionaly the matching channel announcement
- query_short_channel_ids_end_ex is sent when an extended query has been completed

Last feature bit is currently 7, we use bit 15 to not interfere with new
features being added to the LN spec.

The scheme we use to keep tracks of channel queries with each peer would forget about
missing data when several channel_range_replies are sent back for a single channel_range_queries.

* Remove peer entry on our sync map only when we've received
a `reply_short_channel_ids_end` message.
* Make routing sync test more explicit

We must clean up leftovers for the previous session and start the sync process again.

…able dump

When we're reconnected to a peer we will start a new sync process and should reset our sync
state with that peer.

…outing table dump"

This reverts commit 19f0c81.

It will tell us if sender requests channel announcements and updates or just updates

- reply_channel_range include  a list of channel id + both channel update timestamp
- query_short_channl_ids include a list of channel id + flag, where flag specifies what the receiver
should send back (a combination of channel annoucement, channel updated #1 and channel update #2)

Use more descriptive names and specifiy what is specific to our own
prototypes and what is proposed for BOLT 1.1

It is not needed since old implementations will just ignore additional
fields.

* Add missing API endpoints to eclair-cli help

* Fix README style warnings
* Add documentation links to the wiki
* Update build instructions.

* Type all amounts used in eclair

* Add eclair.MilliSatoshi class

* Use bitcoin-lib 0.14

* Add specialized codecs for Satoshi/MilliSatoshi

* Rename 'toSatoshi' to 'truncateToSatoshi' to highlight it's a precision-losing conversion

* Extended Queries: use TLV format for optional data

Optional query extensions now use TLV instead of a custom format.
Flags are encoded as varint instead of bytes as originally proposed. With the current proposal they will all fit on a single byte, but will be
much easier to extends this way.

* Move query message TLVs to their own namespace

We add one new class for each TLV type, with specific TLV types, and encapsulate codecs.

* Optional TLVs are represented as a list, not an optional list

TLVs that extend regular LN messages can be represented as a TlvStream and not an Option[TlvStream] since we don't need
to explicitely terminate the stream (either by preprending its length or using a specific terminator) as we do in Onion TLVs.

No TLVs simply means that the TLV stream is empty.

* Update to match  BOLT PR

Checksums in ReplyChannelRange now have the same encoding as short channel ids and timestamps: one byte for
the encoding type (uncompressed or zlib) followed by encoded data.

* TLV Stream: Implement a generic "get" method for TLV fields

If a have a TLV stream of type MyTLV which is a subtype of TLV, and MyTLV1 and MYTLV2 are both
subtypes of MyTLV then we can use stream.get[MyTLV1] to get the TLV record of type MYTLV1 (if any)
in our TLV stream.

* Extended range queries: Implement latest BOLT changes

Checksums are just transmitted as a raw array, with optional compression as it would be useless here.

* Use extended range queries on regtest and testnet

We will use them on mainnet as soon as lightning/bolts#557 has been merged.

* Address review comments

* Router: rework handling of ReplyChannelRange

We remove the ugly and inefficient zipWithIndex we had before

* NodeParams: move fee base check to its proper place

* Router: minor cleanup

* Channel Range Queries: send back node announcements if requested

This PR adds support for sending back node announcements when replying to channel range queries:
- when explicitly requested (bit is set in the optional query flag)
- when query flags are not used and a channel announcement is sent (as per the BOLTs)

A new configuration option `request-node-announcements` has been added in the `router` section. If set to true, we
will request node announcements when we receive a channel id (through channel range queries) that we don't know of.
This is a setting that we will probably turn off on mobile devices.

* Increase tests timeouts

There is now more work to do.

* Test query sync with and without node announcements

* Router: minor fix

* Router: rework query handling