[#1385] Fix NPE which was triggered if a write was executed but the HeadHandler not init yet
[#1384] Cache HttpHeaderDateFormat in ThreadLocal
[#1388] Ensure AbstractNioMessageChannel based Channels will call fireInboundBufferUpdated() soon enough to release resources
[#1388] Correctly break the loop on exceptions
Fix StackOverflowError in LocalEcho.doBeginRead() when the peer channel keeps writing data

- Fixes #1380
Some optimizations to the http codec
Only call key.interestedOps() if needed
Make sure that setAutoRead(false) has a direct effect and only update interestedOps if needed
No need to clear buffer as it is cleared later anyway and only update interestedOps if needed
No need to create temporary arrays
[#1392] Fix bug where SslHandler returned wrong value for getCloseNotifyTimeoutMillis()
Re-add Unsafe.voidPromise() which can be used for Unsafe operations for which no notification should be done [#1375]
[#1399] DefaultChannelHandlerPipeline.firstContext() should return null if no user handlers are in in the pipeline
Use correct value to disable/enable direct arenas in PooledByteBufAllocator
SPDY: always enqueue data frames if stream is stalled
Merge pull request #1421 from jpinner/spdy_fix_stalled_streams_master

SPDY: always enqueue data frames if stream is stalled
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.