Send MDPW_DISCONNECT when worker is destroyed

As discussed in #45, the worker does not currently provide a mechanism
for informing the broker that it is going away, which may result in
messages routed to the destroyed broker in the time between when it
is destroyed and its heartbeat expires on the broker.  To resolve this,
send MDPW_DISCONNECT when the worker is destroyed.

Note:  This implementation unconditionally sends MDPW_DISCONNECT in
mdp_worker_destroy rather than adding an mdp_worker_destroy function
because MDPW_DISCONNECT should be harmless in all states in which it is
not expected, the overhead should be small, and the adding a
disconnected-but-not-destroyed worker state seemed to add more
complexity than its value.

Fixes #45.

Signed-off-by: Kevin Locke <klocke@quantpost.com>
Add a default linger time and expose it

In order for the DISCONNECT message to be sent, the socket needs to send
data before being destroyed.  The czmq default linger time of 0 won't
work for this case.  Bump it up to 100ms, which should be sufficient, if
there isn't another large send operation queued, but shouldn't
significantly alter the behavior if the broker has gone away and the
messages can't be sent.

Note:  Personally, I contend that a default linger of -1 is closer to
the expected behavior for this sort of protocol, but my assessment was
that it would introduce enough backwards-compatibility issues that a
small value was more reasonable.  Feel free to change this in future
commits if it is deemed less of an issue.

Signed-off-by: Kevin Locke <klocke@quantpost.com>
Merge pull request #46 from kevinoid/disconnect-on-destroy

Disconnecting worker from broker