Select timer timeout

The default `tick_resolution` timeout is 1 second which means that timers that are scheduled under periods when no IO activity is present will only get the chance to run once every second. This pr adds a bit of intelligence to the value of timeout in the `IO.select`call. Specifically if timers are scheduled we will disregard the `tick_resolution` and only wait for IO until it is time to run the first timer.

When scheduling timers from outside the Io::Reactor the reactor may currently be fast asleep in a `IO.select` call. Therefore we should unblock and run `scheduler.tick` once more to run the recently added timer if the added timer timeout is shorter than the earliest present timer or if there is no present timer.
The IO loop could save the absolute time when it will return from `IO.select`, that's all you need.

On the other hand just checking that the new timer will expire before all other timers like you do is enough, I just feel like it's relying on the implicit connection between the timers and the time until the reactor will unblock is unfortunate. It would be better if it were more explicit. Never mind, just keep it as it is.

Although there is one case you're not covering: if `next_timeout` is `nil` the timeout is actually the default timeout of the IO loop. There's no need to unblock the reactor for a timer that expires in 10s when the reactor will wake up anyway in 3.