ChannelHandler type hierarchy simplification

This changeset moves all methods in `ChannelInboundHandler` and `ChannelOutboundHandler` up to `ChannelHandler` and deprecate them and their adapters, greatly simplifying the type hierarchy of handlers by removing the distinction between 'inbound' handlers and 'outbound' handlers.

Because all handlers are now both inbound and outbound handlers, it is not reasonable to provide `CombinedChannelDuplexHandler`, whose purpose was to combine an inbound handler and an outbound handler into a single handler.  Instead, I added a new handler called `ChannelHandlerAppender`, which appends the specified set of handlers together when it's added to the pipeline.

It also introduces an annotation called `@Skip` so that `DefaultChannelHandler` skips the evaluation of the handler methods annotated with `@Skip`.  All handler methods in `ChannelHandlerAdapter` are annotated with `@Skip`, so extending `ChannelHandlerAdapter` will ensure that unoverridden methods are always annotated with `@Skip`. (i.e. most users don't need to know about this annotation unless they override a handler method and reverts back to pass-through mode.)

Thanks to the `@Skip` annotation, we can safely skip the evaluation of many unoverridden handler methods.

Because the inspection of the presence of the annotation relies on reflection, I introduced a simple cache in `DefaultChannelHandlerContext`.  Is uses a partitioned synchronized `WeakHashMap` so I'd say it has a room for improvements, but at the moment, I wouldn't do premature optimization.

Talking about performance, I see slight boost, although it's not very noticeable. (0.5~1k HTTP QPS in my laptop) Simple distributed echo test on Mesos shows no regression (i.e. same latency/throughput. probably because it's just a single handler pipeline?)

This pull request is not complete yet - I'll clean all deprecation warnings and some rough edges soon.