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 If we look at e.g. `EpollDatagramChannel.doWriteMessage()` there are two places that could throw an `Exception`. Either a `NotYetConnectedException` is thrown, in which case no data was written or `Native.sendTo(Address)` throws an `IOException` in which case it will not return the number of bytes written anyway.

So I think it's fine.