The zero copy decoding strategy implemented for 4.2.0 can lead to a large
increase of main memory usage in some cases (I have seen one program go up to
40G from 10G after upgrading from 4.1.4). This commit adds a new option to
contexts, called ZMQ_ZERO_COPY_RECV, which allows one to switch to the old
decoding strategy.

Solution: applied clang-format

Solution: Phase I - make precompiled.hpp be first file included in every source file

Solution: update to 2016

Solution: add explicit cast

Despite the old comments, re-initing the msg_t leaks a refcount to
metadata in some situations.

v1_decoder looks like it isn't tested any more, but it seems like a good
idea to fix it because it has the exact same piece of buggy code
v2_decoder does.

A memcpy is eliminated when receiving data on a ZMQ_STREAM socket. Instead
of receiving into a static buffer and then copying the data into the
buffer malloced in msg_t::init_size, the raw_decoder allocates the memory
for together with the reference-counter and creates a msg_t object
on top of that memory. This saves the memcpy operation.

For small messages, data is still copied and the receive buffer is reused.

The shared reference count was not shared but copied. msg_t cannot
store the refcnt itsef but has to store a pointer to an externally
allocated (shared) refcnter. The changes to lmsg are reverted to
use content_t again. Howver, this introduces an allocation in v2_decoder
when creating the message which can be avoided. When allocating the reception
buffer, space is allocated for the maximum number of reference counts
(8192 / max_vsm_size = 8192/64 = 128 zmq:atomic_counter objects). This
increases the buffer by 128*sizeof(atomic_counter) = 128*4 = 512 bytes only.
When creating a message, the refcnt member is set to the address of one of the
pre-allocated atomic_counter_t objects. To do so, a new msg_t type zcmsg
is introduced because msg::copy must discriminate between the message types
when releasing memory.

zero-copy msg_t::init cannot be used when the message exceeds either
the buffer end or the last received byte. To detect this, the buffer
is now resized to the numnber of received bytes.

Construct messages from a reference-counted buffer allocated once
per receive instead of copying the data.

Of course people still "can" distributed the sources under the
LGPLv3. However we provide COPYING.LESSER with additional grants.

Solution: specify these grants in the header of each source file.

Solution: update for 2015

Fixes #1320

* Command names changed from null terminated to length-specified
* Command frames use the correct flag (bit 2)
* test_stream acts as test case for command frames
* Some code cleanups

Copyrights had become ads for Sustrik's corporate sponsors, going against the original
agreement to share copyrights with the community (that agreement was: one line stating
iMatix copyright + one reference to AUTHORS file). The proliferation of corporate ads
is also unfair to the many individual authors. I've removed ALL corporate title from
the source files so the copyright statements can now be centralized in AUTHORS and
source files can be properly updated on an annual basis.

This is supposed to become part of the ZMTP/1.1.

The main differences from the ZMTP/1.0 framing protocol are:
- flags field comes first, followed by the length field
- long messages are signaled using a flag rather then 0xff escape
- length field does not include the flags field, 0 is a valid value