Revamp the core API to reduce memory footprint and consumption

The API changes made so far turned out to increase the memory footprint
and consumption while our intention was actually decreasing them.

Memory consumption issue:

When there are many connections which does not exchange data frequently,
the old Netty 4 API spent a lot more memory than 3 because it always
allocates per-handler buffer for each connection unless otherwise
explicitly stated by a user.  In a usual real world load, a client
doesn't always send requests without pausing, so the idea of having a
buffer whose life cycle if bound to the life cycle of a connection
didn't work as expected.

Memory footprint issue:

The old Netty 4 API decreased overall memory footprint by a great deal
in many cases.  It was mainly because the old Netty 4 API did not
allocate a new buffer and event object for each read.  Instead, it
created a new buffer for each handler in a pipeline.  This works pretty
well as long as the number of handlers in a pipeline is only a few.
However, for a highly modular application with many handlers which
handles connections which lasts for relatively short period, it actually
makes the memory footprint issue much worse.

Changes:

All in all, this is about retaining all the good changes we made in 4 so
far such as better thread model and going back to the way how we dealt
with message events in 3.

To fix the memory consumption/footprint issue mentioned above, we made a
hard decision to break the backward compatibility again with the
following changes:

- Remove MessageBuf
- Merge Buf into ByteBuf
- Merge ChannelInboundByte/MessageHandler and ChannelStateHandler into ChannelInboundHandler
  - Similar changes were made to the adapter classes
- Merge ChannelOutboundByte/MessageHandler and ChannelOperationHandler into ChannelOutboundHandler
  - Similar changes were made to the adapter classes
- Introduce MessageList which is similar to `MessageEvent` in Netty 3
- Replace inboundBufferUpdated(ctx) with messageReceived(ctx, MessageList)
- Replace flush(ctx, promise) with write(ctx, MessageList, promise)
- Remove ByteToByteEncoder/Decoder/Codec
  - Replaced by MessageToByteEncoder<ByteBuf>, ByteToMessageDecoder<ByteBuf>, and ByteMessageCodec<ByteBuf>
- Merge EmbeddedByteChannel and EmbeddedMessageChannel into EmbeddedChannel
- Add SimpleChannelInboundHandler which is sometimes more useful than
  ChannelInboundHandlerAdapter
- Bring back Channel.isWritable() from Netty 3
- Add ChannelInboundHandler.channelWritabilityChanges() event
- Add RecvByteBufAllocator configuration property
  - Similar to ReceiveBufferSizePredictor in Netty 3
  - Some existing configuration properties such as
    DatagramChannelConfig.receivePacketSize is gone now.
- Remove suspend/resumeIntermediaryDeallocation() in ByteBuf

This change would have been impossible without @normanmaurer's help. He
fixed, ported, and improved many parts of the changes.
Fix compilation error
[#1422] ReadOnlyByteBuffer.isWritable() should return false
[#1430] Fixed byte order problem on little endian platforms that support Unsafe but not unaligned memory access.
[#1425] Allow to access the EventLoopGroups via the Bootstraps
[#1414] Use gathering writes in AbstractMemoryHttpData if the buffer is backed by multiple ByteBuffers

* This fix the bug which caused an UnsupportedOperationException when renameTo(...) was called and the underlying ByteBuf was backed by multiple ByteBuffers
[#1411] Correctly check for null in AbstractTrafficShapperHandler.read() and so prevent NPE
Optimize Recycler.Stack

- No need to use a deque at all
- Increase the initial capacity so that there's no practical chance of capacity expansion
Add ChannelHandlerContext.isRemoved() to easily detect the removal of a ChannelHandler while in a method.
Simplify the logic for updating OP_WRITE in the NIO transport

- Removed code duplication
Remove an unnecessary empty line
Remove the AIO transport as NIO is just faster

The AIO transport was added in the past as we hoped it would have better latency as the NIO transport. But in reality this was never the case.
So there is no reason to use the AIO transport at all. It just put more burden on us as we need to also support it and fix bugs.
Because of this we dedicided to remove it for now. It will stay in the master_with_aio_transport branch so we can pick it up later again if it is ever needed.
Add ResourceLeakDetector.ENABLED

.. to provide a way to check if resource leak detection was enabled programmatically.
Recycle PooledByteBuf partially

- Related issue: #1397
- Resource leak detection should be turned off and the maxCapacity has to be Integer.MAX_VALUE
- It's technically possible to pool PooledByteBufs with different maxCapacity, which will be addressed in another commit.
Remove MessageList.remove(*) , MessageList.set(*) and MessageList.add(i,*)
Merge branch 'master' of github.com:netty/netty
Optimize the way messages are added from one MessageList to another one
Add javadocs
Optimize PooledUnsafeDirectByteBuf.newInternalNioBuffer()

- No need to produce garbage
SPDY: update object hierarchy