Implemented some experimental event loops with nextTick() support.

**I fully expect that this PR will be rejected in its current form, but I needed a place to start a discussion about it.**

This pull-request attempts to provide a reliable way to register callbacks on the event-loop that are executed with the following guarantees:

On each tick of the engine:

 * the callbacks are executed in the same order as they are enqueued
 * the callbacks are executed before any pending timer or IO events
 * callbacks registered within an existing callback will also execute before IO events

As best I can tell this matches the current behaviour of `process.nextTick()` in nodejs (0.10.x), and as such I have dared to call the feature 'nextTick'. Please correct any misconceptions I have about this :) (see #92)

There is one new interface:

 * `NextTickLoopInterface` - adds the `nextTick()` method to the existing `LoopInterface`

And two implementations:

 * `ExtEventLoop` - uses ext-event (OOP bindings for libevent, see #161)
 * `StreamSelectNextTickLoop` - a stream_select() based loop

Both implementations are tested against the existing abstract test cases for loops and timers.

I haven't had a chance to try `libev` or `libuv` yet, but I will attempt to provide implementations based on both of those libraries if this PR is well received.

I chose not to completely replace the existing `stream_select()` based loop at this stage, but there is no reason it would need to remain if the implementation proposed in this PR is accepted in the future.

Finally, I also added some doc-blocks to `LoopInterface` to clarify the guarantees made in regards to timer behaviour (in contrast to nextTick() behaviour) and return values.

**Edit:**
Notably absent is any concept of minimum resolution for timers, I was speaking with @nrk about this on IRC and we talked about the possibility of allowing users to configure the resolution, perhaps that is now unnecessary.