Rework Message.t

[Gau-thier]

Message.t actually contains the recipient which is a list.
On failure_detector having a list could lead to confusion.

SWIM exchanges direct messages between peers. Except when the status of a peer change (e.g. from Alive to Suspicious).

This can be easily done by creating dedicated Message.t for failure_detector module, or perhaps, by refactoring Message.t to something like GADT.

Originally posted by @gsebil08 in #33 (comment)

[rosalogia]

I am not particularly convinced that encoding the specific number of expected recipients for a message at the type level is necessary. My opinion is that keeping recipients as a list is the right level of flexibility, especially since the interfaces we design for constructing messages can be more restrictive as to how the recipients list is populated. For example, all functions responsible for creating Failure detection messages only accept a single recipient, and then construct a message whose recipient list contains only that single recipient. If users stick to these interfaces, they should never accidentally construct a Failure detector message with more or less than 1 recipient. Using a GADT here may complicate how the message is encoded with Bin_prot, but this is not totally clear and is just speculation.