ForkJoinPool-based EventLoopGroup and Channel Deregistration

Hey,

this is a first version of Netty running on a ForkJoinPool and deregister (hopefully) working correctly. The main idea behind the changes in deregister is that deregister is always executed as a task and never invoked directly. We also do not allow any new task submissions after deregister was called, making the deregistration task the last task of a particular Channel in the task queue and we thus do not have to worry about moving tasks between EventLoops. We achieve this mainly by wrapping all calls to .eventLoop() and .executor(). There is some special treatment required for scheduled tasks, but this is best explained in the code.

Let me know what you guys think.

@normanmaurer @trustin
@trustin I think this is neither a good nor a necessary change.

I would argue it's not good because ```AbstractChannelHandlerContext``` would become a full blown ```EventExecutor``` and ```ChannelHandlerInvoker```. The inheritance tree and 99% of the methods just don't make sense here. I think from a design perspective this would not be justifiable. The API would be horrible.

It's not necessary because this code will hardly ever get executed. A developer has to specify a custom ```EventExecutorGroup``` for the ```ChannelHandler``` and call ```ctx.executor()``` for this code to run.

If you really feel strongly about this, I ll have to come up with something else, as I am confident that inheritance is not the way to go here.