SocketHandler has been renamed to TCPSocketHandler
SocketHandler is now a simple interface with a few methods, used only by
Poller.

This way we can inherite from the new SocketHandler class, to handle other
types of sockets, and still make them manageable by the poller without any
change in the Poller class.

ref #2455

A result or an error, depending on the type of message

For example, both JID #chan%server@biboumi/Toto and toto!server@biboumi are
equivalent, except that if you send a message to the first one, subsequent
messages coming from the user toto will come from that same JID. This is
done to be consistent for the XMPP user, and respond from the same JID than
the 'to' of the first message.

fix #2468

IRC users and channels are now distinguished by the separator used in the
IID (% or !).

ref #2468

We have two basic example commands. But it’s not entirely finished because
there are some error checks that we don’t do.

ref #2521

We want to call socket() with the parameters provided by getaddrinfo, so we
can’t addd the fd into the poller immediately. We need to wait the
connection attempt, and then the SocketHandler can call add_socket_handler
itself, if the connection succeeds, or is in progress.

Whether this is a bad-request (missing XML attributes or elements) or an
internal server error.

If we never succeeded our connection+auth process, means we should probably
not attempt any-more, and just give up.  If we ever did, this means a
reconnect is a good idea

Also remove the duplicate send_self_join methods, user only send_user_join

The generated XML is very verbose because each IRC formatting tag makes us
close a <span/> element and reopen it with the new style applied.  However,
this works quite well and is easy to implement.

Also correctly respond to PING with the id, escape some XML content, but not
always