if TSC jumps backwards (in case of migration to a different CPU core) latency peak may occur -- fixed

Thanks to Matt Weinstein for the suggestion.

Change 'make dist' to generate the Git ChangeLog file, that way it doesn't
have to be manually updated nor kept in Git which causes unnecessary work.

Also change 'make dist' to invoke 'dist-zip' automatically to generate a
ZIP as well as a .tar.gz.

Thanks to http://live.gnome.org/Git/ChangeLog for the inspiration to
automatically generate ChangeLog.

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)