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.
`Scheduler#timeout` calculates the next time a timer will run based on the current time.

The IO loop does not currently save any information on the current value for it's timeout. Unfortunately the timeout is not enough information since time may have passed since it entered it's selecting state. It would also need to copy the time of the next timer and expose it or defer the answer to the question back to the scheduler. 

Semantically the Io::Reactor should ask the IO Loop about the next time it timeout. I not quite sure if we should pass the next timeout time to the IO Loop for every tick or if we should inject the scheduler and defer to it from the IO Loop. What are your thoughts on this matter?