Implemented LoopInterface::futureTick() (aka setImmediate, kind of).

This is an attempt to approximate NodeJS's `setImmediate`.

There's probably some discussion to be had about how necessary this is. I think it *is* necessary, as without it there is no way to execute user code on each tick of the engine without starving IO/timers (`nextTick` is too greedy).

The implementation is identical to `nextTick`, except that callbacks registered inside an existing `futureTick` handler will **not** be processed on the same tick. In other words, when the future-tick queue is processed, only the callbacks that were already on the queue are executed. With this implementation, `futureTick` should generally be favoured over `nextTick` unless you specifically need the stricter guarantees of `nextTick`.

Some possible changes are:
* Simply process one item from the queue each tick. The upside would be more frequent checks for stream and timer activity when the future-tick queue is large. This could also be considered a downside if those checks are expensive and the callbacks are cheap (perhaps?).
* Move processing of the future-tick queue after timers/streams. I *think* this would more closely mirror the behaviour of `setTimeout` but I'm not sure it's strictly necessary.
* The name `futureTick` itself; I'm sure this will be controversial :P

Again, this can wait until after [loop-enable-disable](https://github.com/reactphp/react/tree/loop-enable-disable). I am more than happy to update the implementation at that time. I'd also need to add support to `ExtEventLoop` from #248.