Fixed issue LIBZMQ-526

Fixed issue LIBZMQ-525

Throughput perf test was borked, fixed it

as I can see, these didn't work any more. At the very least, the command line
API was broken and forced the user to enter new, exotic arguments. Patches
should not break existing APIs. But also, the internals of these programs had
become weird.

If we want to build more complex performance tests, that's fine, but we should
make new programs, not break the old ones. We need minimal, safe performance
tests in 0MQ.

Also, the code was quite horrid. So it's gone. If anyone wants to bring it back
please make the code neat, and build new APIs instead of breaking the old ones.

Cheers
Pieter

contributors and doesn't reflect the real process. I've taken out all named
authors and referred to the contribution policy. Hopefully this will improve
the contributions to the man pages.

Interoperate with higher versions of ZMTP protocol

[#LIBZMQ-446] Silence error on setting PGM_TOS on REL 4.

[#LIBZMQ-446] Silence error on setting PGM_TOS due to some platforms raising an error at runtime. Noted are RHEL 4.

MSVC local_thr & remote_thr dependency fix

Add platform.hpp as project dependency to vc100 and vc110 projects for local & remote throughput tests.

Use state functions for message flow

The patch makes the code somewhat simpler and prepares it for
more complex initialization handshakes.

Refactor code so that messages go through engines

Small clarification about connect and ROUTER

Adds a needed Windows system library dependency

MSVC fixes

Use Multithreaded DLL Runtime, Debug/Release accordingly - need consistency for the czmq configurations

mingw32 fixes

Fixed test_last_endpoint (#80)

Reverted cleanups of copyrghts

Optimize atomics implementaiton for the Tile architecture

For atomic_counter and atomic_ptr classes, detect the Tile architecture
using #if defined __tile__ matching ARM and Solaris and then use the
Tile atomic instructions. Without this change, the default Mutex
implementation is used, which is slower.

Work around for LIBZMQ-496

The problem is that other threads might still be in mailbox::send() when
it is destroyed. So as a workaround, we just acquire the mutex in the
destructor. Therefore the running send will finish before the mailbox is
destroyed.

See also the fix for LIBZMQ-281 in zeromq2-x.
Signed-off-by: Mika Fischer <mika.fischer@zoopnet.de>