Improve performance of StreamSelectLoop when no timers are scheduled

[clue]

This simple changeset improves performance of the StreamSelectLoop when no timers are scheduled. This can be reproduced by running the included benchmarks (#100):

me@me-mate:~/workspace/reactphp-event-loop$ time php examples/93-benchmark-ticks-delay.php 1000000
// old: 1.8s
// new: 0.5s

In a very busy loop constantly using futureTick() like this example, this shows a significant improvement. For many "normal" workloads that have any reasonable stream activity, this improvement is expected to be negligible. At the very least, this changeset is expected to offset any negative impact #245 may show, but in some cases you may even be able to see a significant improvement.

The idea behind this PR is to avoid any unnecessary system calls as these incur a significant overhead. In the previous version, you would constantly see a bunch of system calls here:

me@me-mate:~/workspace/reactphp-event-loop$ strace php examples/93-benchmark-ticks-delay.php 1000000
[…]
clock_gettime(CLOCK_MONOTONIC, {tv_sec=1834904, tv_nsec=318373419}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=1834904, tv_nsec=318397235}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=1834904, tv_nsec=318421121}) = 0
// repeated 1 Mio times for old version
[…]

In the updated version, these system calls are no longer issued. Once any timers are scheduled, this system call is issued as usual (which is why this has little effect on many real-world workloads). The test suite confirms this has full code coverage.

This benchmark is interesting because it actually skips any system calls entirely (as of #93). If the same benchmark is updated to add an idle stream, the loop has to invoke a select() system call on each tick at least. In this case, the benchmark improved from 2.6s to 1.3s on my machine.

As a worst-case scenario, you can also execute time php examples/94-benchmark-timers-delay.php which constantly schedules a single timer for the next loop iteration. With or without my changes, this shows 7.1s on my machine, so this confirms my changeset does not negatively impact performance.

Builds on top of #245, #183, #182, #93, and others