Selector registration modification coalescing

[hassila]

Motivation:

As discussed during the review of #1804, there is room for optimising the modification of registrations vis-a-vis the kernel. Basically the idea is to coalesce all the registration modifications (register0/reregister0/deregister0) and perform them in bulk before waiting for the next event in whenReady0.

It makes the implementation more resilient to degenerate cases (and tests...) by limiting the maximum amount of outbound modifications to be the same as the number of channels (fds) we have.

Result:

More robust handling of large number of registration modifications - and less system calls when coalescing occurs. Also removes the risk of "starvation" due to lack of reaping CQE:s while generating huge amount of SQE:s for io_uring.