Fixed bogus reference to zmq_ctx_put

Doc improvement: document interface omission in zmq_pgm.txt

Solaris/SunCC build fix: could not find a match for std::multimap<...>::insert(std::pair<...,...>)

The PGM transport supports the omission of the network interface to
select the default one like:

  announce.connect("epgm://eth0;239.255.128.46:64646"); // Use eth0
  announce.connect("epgm://239.255.128.46:64646"); // Use the default

Also, mention C++ in the additional community bindings of 0MQ in
zmq.txt.

Rename type zmq_monitor_fn -> zmq_monitor for a more natural callback definition API (zmq_monitor type, monitor.function callback)

Change zmq_monitor_fn type to cast between pointer-to-object and pointer-to-function in a more standards compliant way

Allow the ZMQ_MONITOR code compilable on gcc 4.7 on Linux.

The current ZMQ_MONITOR code does not compile in gcc 4.7, as -pedantic
and -Werror are enabled, and ISO C++ doesn't allow casting between
normal pointers (void*) and function pointers, as pedantically their
size could be different. This caused the library not compilable. This
commit workaround the problem by introducing one more indirection, i.e.
instead of calling

    (void *)listener

which is an error, we have to use

    *(void **)&listener

which is an undefined behavior :) but works on most platforms

Also, `optval_ = monitor` will not set the parameter in getsockopt(),
and the extra casting caused the LHS to be an rvalue which again makes
the code not compilable. The proper way is to pass a pointer of function
pointer and assign with indirection, i.e. `*optval_ = monitor`.

Also, fixed an asciidoc error in zmq_getsockopt.txt because the `~~~~`
is too long.

Expose a ZMQ_MONITOR socket option to register a callback for notification of state changes in socket state ( stream engine, tcp and ipc transport only )

Add disconnect and unbind documentation

Fix #366 - On Windows, preventing sockets to be inherited by child processes.

Simplify encoder's loop

Fix issue #268

This patch fixes a bug in the message encoder which was
responsible for computing incorrect message offset.
The bug affected PGM receiver making it unable to
decode inital messages.

Fix for issue 355 and fix for compile error with Visual C++ 2008

File decoder.cpp does not compile with Visual C++ 2008:

1>c:\tmp\libzmq\src\decoder.cpp(117) : warning C4003: not enough actual parameters for macro 'max'
1>c:\tmp\libzmq\src\decoder.cpp(117) : error C2589: '(' : illegal token on right side of '::'
1>c:\tmp\libzmq\src\decoder.cpp(117) : error C2059: syntax error : '::'
1>c:\tmp\libzmq\src\decoder.cpp(117) : error C2143: syntax error : missing ';' before '{'

This error is caused by the precense of a macro 'max' when including
'windows.h'. To solve this problem, the preprocessor macro /DNOMINMAX must
be specified.

Fix for issue 355. Added missing source files dealer.cpp, device,cpp and router.cpp. Removed source files no longer present: xrep.cpp and xreq.cpp

Async connect error handling

Patch from Mato that fixes a subtle connect bug: EAGAIN was being used as a translation value for EINPROGRESS, thus
shadowing a real EAGAIN return value from the OS.  This caused later
assertions of "Invalid argument" in stream_engine.cpp when it attempted to
use a socket which was not connected.

I also add EINTR to mean EINPROGRESS, as per the POSIX and FreeBSD
documentation which specifies that a connect() call interrupted due to a
signal will complete asynchronously.
Signed-off-by: Martin Lucina <martin@lucina.net>

Fix decoder to properly handle large messages

Fix issue #264

socket_base: process_unplug () is not used, remove it

Do not crash when multiple peers connect to PAIR socket

When more then one peer connected to a ZMQ_PAIR socket,
an application aborted due to assertion failure.
This patch changes the ZMQ_PAIR socket behaviour so that
it rejects any further connection requests.

The decoder did not properly decode large messages
on systems where sizeof (size_t) < sizeof (uint64_t).

Before this patch, the stream engine terminated itself
whenever it had detected an IO error. If this happened
when sending a message, the engine lost all
in-flight messages, messages waiting to be decoded,
and the last decoded message that had not been accepted,
if there was one.

The new behaviour is to terminate the engine only after
the input error has been detected and the last decoded