Fix nioBuffer implementation for CompositeByteBuf
[#1836] Add comment to explain why read is triggered
More efficient handling of incomplete writes.

The problem with the old way was that we always set the OP_WRITE when the buffer could not be written
until the write-spin-count was reached. This means that in some cases the channel was still be writable
but we just was not able to write out the data quick enough. For this cases we should better break out the
write loop and schedule a write to be picked up later in the EventLoop, when other tasks was executed.
The OP_WRITE will only be set if a write actual returned 0 which means there is no more room for writing data
and this we need to wait for the os to notify us.
[#1852] Fix bug in UnpooledDirectByteBuf.nioBuffer(...) implementation
[#1853] Optimize gathering writes for CompositeByteBuf that are only backed by one ByteBuffer
Slip in DefaultOioSocketChannelConfig (setAllowHalfClosure used to ignore argument)
[#1851] EmptyByteBuf.isWritable(..) and isReadable(...) should not throw IndexOutOfBoundsException
HttpRequestEncoder should append '/' to absolute path requests only when needed
[#1855] Try to calculate the correct amount of written bytes to update the ChannelProgressiveFuture
Introduce a new ChannelOption called DATAGRAM_CHANNEL_ACTIVE_ON_REGISTRATION. Related to [#1830]

This ChannelOption allows to tell the DatagramChannel implementation to be active as soon as they are registrated to their EventLoop. This can be used to make it possible to write to a not bound DatagramChannel.
The ChannelOption is marked as @deprecated as I'm looking for a better solution in master which breaks default behaviour with 4.0 branch.
Correctly handle automatically suspend/resume in ChunkedWriteHandler. Related to [#1861]

The old implementation was broken and could lead to pending message never be picked up again until the user either explicit called flush or
resumeTransfer().
Propagate channelWritabilityChanged() through the pipeline after flushing. Related to [#1861]
[#1865] Only use internalNioBuffer when one of the read* or write* methods are used. This is neccessary to prevent races as those can happen when a slice or duplicate is shared between different Channels
that are not assigned to the same EventLoop. In general get* operations should always be safe to be used from different Threads.

This aslo include unit tests that show the issue
CompositeByteBuf.isDirect() should return true if its only backed by direct buffers
Cache underlying ByteBuffers and count in ChannelOutboundBuffer.Entry to reduce object creation and so GC pressure

Beside this it also helps to reduce CPU usage as nioBufferCount() is quite expensive when used on CompositeByteBuf which are
nested and contains a lot of components
SPDY: add SPDY/3.1 support

- with Michael Schore <mschore@twitter.com>
[#1875] Correctly check the readerIndex when try to read a byte from AbstractByteBuf
[#1832] - Channel writability change notifications sometimes fail to fire
[#1874] WebSocket08FrameDecoder may leak memory if channel is closed before the full frame was received
[#1878] Fix leak of ByteBuf when masked payload is used