Pluggable algorithm to choose next EventLoop

Hello,

this PR introduces a way for developers to plug their own `Next-EventLoop Algorithm` into `NioEventLoopGroup` and `EpollEventLoopGroup`. Additionally an API to gather metrics from the `EventLoop`s is introduced.

This PR is still missing most of the tests. I haven't been able to execute on my GENIUS vision of a unified test class for all `Channel` / `EventLoop` implementations that use a `MetricsCollector` YET. So I didn't include this code here (it's coming and something to look forward to though :smile: ). Despite that, I think the code is ready to get some feedback from @normanmaurer and @trustin.

Some issues I would love to get you guys input on:
* I am not a fan of the name `MetricsCollector.(start|stop)processIo()`. Would be thankful for naming suggestions.
* I think `EventLoopChooser` sounds odd. How about `EventLoopScheduler`? That sounds more powerful.
* I think it would make sense to extend the `(Nio|Epoll)EventLoopGroup` constructors to additionally accept a standalone `MetricsCollectorFactory` object (and also have `EventLoopChooser` implement this interface). That way a user could only gather metrics and continue to use the default `EventLoopChooser`.
* Since @normanmaurer and I decided to gather metrics by integrating the metric hooks directly into the code, instead of using a separate `ChannelHandler` we have more freedom in which metrics to collect. Anything missing in the current implementation that would be useful?

Thanks,
Jakob
I just wonder what will happen if something was partial written and then an Exception is thrown. In this case we will lose the information about how many bytes were written. Not sure if we really need to care about this though. Just wanted to throw in some thoughts...