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.
Is there a reason for doing the `#next_tick_before?` call before the scheduling? Otherwise doing it in the `unless` would be shorter and easier to read. As it is now it looks like there's a reason why it must be done before the scheduling, but I can't see it. If anything it would be better to figure out if the reactor needs to be unblocked later, since it might already have been unblocked by that time.