zhttpsocket: for server mode, add ability to respond via router socket

[jkarneges]

The IPC protocol used between Pushpin components (ZHTTP) is based on ZeroMQ, where response data is sent via a PUB socket. The use of PUB here makes backpressure difficult and likely leads to message loss under high load. It would make more sense to use a socket type with backpressure, such as PUSH or ROUTER. This PR is the first in a series to enable response data via ROUTER. It uses the ROUTER socket that already exists for request data which is bidirectional, so we don't need to introduce a new socket.

Background: PUB was intended to enable one-to-many communication, but we don't use our IPC in that manner and it wouldn't be practical to do so since messages are always addressed to specific components. The decision to use PUB here is mainly an artifact of connmgr originally being modeled after mongrel2 which also uses PUB for response data. I suppose the idea was that you could set up multiple connmgrs and reach all of them with a single ethernet packet via UDP multicast. In theory that sounds interesting but I don't really see us ever doing that.

To start out, this PR enables sending response messages via ROUTER, by adding an optional address argument to the server mode handle's send method. If set to Some, the message is sent via ROUTER to the supplied address, otherwise the message is sent via PUB (where the address is expected to be embedded in the message content). All existing send calls are updated to pass None, so there is no change in behavior. In a future PR we can change the calls to pass Some to send via ROUTER.