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
@normanmaurer Yeah that's a remainder from when I was experimenting.

Do you think `Unsafe.(read|flush)` should return the number of bytes and then the metrics call should happen in the `EventLoop`? I am undecided.