Problem: randomly claiming "lost messages" after reconnects

The sequence detection logic was not correct, and when receiving a
HELLO from a disconnected/reconnected peer, would complain that it
did not expect the sequence number (1).

Solution: clarify in RFC 36 that HELLO always has sequence = 1.

Then, when receiving a message, if it's HELLO, reset expected
sequence to 1.

Lastly, when getting a bad sequence, delete the peer.
Updated man pages
Cleaned-up endpoint announcement

In gossip model, caller specifies bind/connect endpoints explicitly
both for the ZRE protocol and for the zgossip protocol. The API now
tries to explain these better, and provide a method to set the
announced endpoint for ZRE, when it's not the same as the bind
value. Note that zbeacon does all this behind the scenes...
Updated man pages
Fixed Windows build errors (strndup not portable)

Fixes #223
Merge pull request #224 from hintjens/master

Fixes for Windows and HELLO sequencing