Automatic diagnosis of resource leaks

Now that we are going to use buffer pooling by default, it is obvious
that a user will forget to call .free() and report memory leak. In this
case, we should have a tool to determine if it is a bug in our allocator
implementation or in the user's code.

This pull request adds a system property flag called
'io.netty.resourceLeakDetection'. If set, when a user forgets to call
.free(), the ResourceLeakDetector will detect it and log a message with
detailed stack trace to tell where the leaked buffer has been allocated.

Because obtaining stack trace is an expensive operation, I used sampling
technique. Allocation is recorded only for every 113th allocation. I
chose 113 because it's a prime number.

In production, a user might not want to enable this option due to
potential performance impact. If a user does not specify the
'-Dio.netty.resourceLeakDetection' option leak detection is disabled.

Even if the leak detection is enabled, the overhead should be less than
5% because only ~1% of allocations are monitored.

I also replaced SharedResourceMisuseDetector with ResourceLeakDetector.
Overhaul pipeline implementation for clarity and memory efficiency

This pull request cleans up our pipeline implementation by moving most
inter-context traversal code to DefaultChannelHandlerContext.
Previously, outbound traversal was done in DefaultChannelPipeline while
inbound traversal was done in DefaultChannelHandlerContext.

Also, to address the memory inefficiency issue raised in #920, all
runnables are lazily instantiated.
[#677] Overhaul HTTP codec

This commit tries to simplify the handling of Http easier and more consistent. This has a effect of many channges. Including:
 - HttpMessage was renamed to HttpHeader and the setContent and getContent methods were removed
 - HttpChunk was renamed to HttpContent
 - HttpChunkTrailer was renamed to LastHttpContent
 - HttpCodecUtil was merged into HttpHeaders

Now a "complete" Http message (request or response) contains of the following parts:
 - HttpHeader (HttpRequestHeader or HttpResponseHeader)
 - 0 - n HttpContent objects which contains parts of the content of the message
 - 1 LastHttpContent which marks the end of the message and contains the remaining data of the content

I also changed the sematic of HttpResponse and HttpRequest, these now represent a "complete" message which contains the HttpHeader and the HttpLastContent, and so can be used to eeasily send requests. The HttpMessageAggregator was renamed to HttpObjectAggregator and produce HttpResponse / HttpRequest message.
[#917] Move transport depending ChannelOption to the specific transport to make it consistent
[#943] Fix CanceledKeyException which can happen on frequently deregister/register while using the NIO Transport
Second HTTP overhaul

- Rename message types for clarity
  - HttpMessage -> FullHttpMessage
  - HttpHeader -> HttpMessage
  - HttpRequest -> FullHttpRequest
  - HttpResponse -> FulllHttpResponse
  - HttpRequestHeader -> HttpRequest
  - HttpResponseHeader -> HttpResponse
- HttpContent now extends ByteBufHolder; no more content() method
- Make HttpHeaders abstract, make its header access methods public, and
  add DefaultHttpHeaders
- Header accessor methods in HttpMessage and LastHttpContent are
  replaced with HttpMessage.headers() and
  LastHttpContent.trailingHeaders(). Both methods return HttpHeaders.
- Remove setters wherever possible and remove 'get' prefix
- Instead of calling setContent(), a user can either specify the content
  when constructing a message or write content into the buffer.
  (e.g. m.content().writeBytes(...))
- Overall cleanup & fixes
Take advantage of invocation chaining in HttpHeaders
Change the WebSocket API to use HttpHeaders instead of Map<String, String> for custom headers / Cleanup
Fix bad test name
Fix a bug where HttpContents are freed too early
SPDY: fix improper use of SYNC_FLUSH in SpdyHeaderBlockZlibCompressor
Merge pull request #946 from jpinner/spdy_fix_compression_master

SPDY: fix improper use of SYNC_FLUSH in SpdyHeaderBlockZlibCompressor
SwappedByteBuf.unwrap() should return null

Fixes #945.  For swapped wrapped buffers, it should not return null.
Ensure cascaded derivation of a buffer does not result in an infinitely nested buffer.
Hide the constructors of ChannelOption to force using dedicated option type
[#910] Make use of ByteBufHolder in SPDY, HTTP multipart and WebSockets to allow for buffer pooling
Tighten visibility
Remove 'get' prefix
Remove 'get' prefix
Fix checkstyle