Ensure that 0MQ does not attempt to call select() on more than FD_SETSIZE
file descriptors.

This reverts commit f575f252.

Conflicts:

	doc/zmq_device.txt

This reverts commit 6cd90304.

This reverts commit 77a3c36f.

This reverts commit c51de31f.

This reverts commit 6ff19399.

This reverts commit 13f3481e.

Conflicts:

	doc/zmq_device.txt
	doc/zmq_tcp.txt

This reverts commit 96bcc9e6.

This reverts commit de017375.

This is because as it adds the 255th element at a node it attempts to calculate
the count member var which is an unsigned char via count = (255 -0) + 1; and
pass the result to realloc. Unfortunately the result is zero and realloc returns
null; the prefix_tree asserts. I have fixed it by making the count an unsigned
short.

I was hitting an issue with an SCL enabled STL library in connection with the
way select_t::loop was erasing retired fd's. The problem as identified by the
SCL assertion was that by the time the iterator given to the erase method was
called it was considered invalid by the library. I am not sure this isn't just
a "quirk" of the MSVC STL library as the other code looks valid to me as well.

Add some basic documentation for XREQ/XREP socket types, including
a brief description of the most common use case (REQ -> XREP) and (XREQ ->
REP).

Function returning unsigned long int cannot return (-1)

http://github.com/zeromq/zeromq2/issues#issue/46
Invalid messages are now discarded silently, instead of causing an assertion
failure.

* Fixed zmq_term, zmq_socket, zmq_close, zmq_setsockopt,
* zmq_getsockopt, zmq_bind, zmq_connect, zmq_send,
* zmq_recv, zmq_poll, zmq_device, zmq_stopwatch_stop
* Updated Reference Manual for these methods

* zmq_term
* zmq_socket
* zmq_close
* zmq_setsockopt
* zmq_getsockopt
* zmq_bind
* zmq_connect
* zmq_send
* zmq_recv
* zmq_poll
* zmq_device
* zmq_stopwatch_stop