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
Also please rephrase the javadocs to just explain what the parameter is for.