Problem: lazy hit gathering is vulnerable to deallocation

If the matched string is freed before a hit is accessed, the hit
returns garbage.

Solution: collect all hits immediately on match success. Also,
reduce heap use by using a single memory chunk for all hits, rather
than one chunk per hit.
Problem: zauth_v2 was causing access violation in libzmq

Under valgrind, libzmq hit this error:

==25942== Thread 5:
==25942== Invalid read of size 1
==25942==    at 0x4E5F8C8: zmq::pipe_t::check_read() (pipe.cpp:121)
==25942==    by 0x4E517AB: zmq::io_thread_t::in_event() (io_thread.cpp:73)
==25942==    by 0x4E5069D: zmq::epoll_t::loop() (epoll.cpp:166)
==25942==    by 0x4E79495: thread_routine (thread.cpp:86)
==25942==    by 0x50A0E99: start_thread (pthread_create.c:308)
==25942==    by 0x55AF3FC: clone (clone.S:112)
==25942==  Address 0x58 is not stack'd, malloc'd or (recently) free'd

Caused by the final test:

    zauth_destroy (&auth);
    success = s_can_connect (ctx, &server, &client);

Due, I think, to deallocating the ZAP socket while using it from inside libzmq.

Solution: explicitly destroy ZAP socket, after doing unbind (that doesn't seem
to change anything but is neat).
Problem: zsock_bind return code treats TCP as special case

For all transports, return code is 0 or -1, except for tcp://
where it's >= 0 or -1. This makes calling code more complex than
it should be.

Solution: add explicit zsock_endpoint property that returns last
bound endpoint. Apps can then treat zsock_bind return code as
0 / non-zero, and get the real endpoint explicitly.
Fixed accidental garbage in comment
Problem: still failing libzmq issue #1169

Solution: add a small pause after destroying ZAP handler.
Problem: various small issues with zinterface

- memory leak on self->name
- blank line after method header
- CZMQ_EXPORT dangling in one case
- iterator in test case could be simpler

Solution: fixed these.
Updated zsock man page for zsock_endpoint
Fixed memory leak in zring selftest
Added workaround for libzmq issue #1169
Merge pull request #627 from hintjens/master

Bunch of stability fixes