Factor Twisted support out to a separate, optional module

This branch brings major factoring changes, with the main goal of separating the Twisted support into a separate optional module.

The core callback-running code was greatly simplified by the use of an asynchronous CPS-style trampoline, and some minor abstractions that allow us to deal with either synchronous or asynchronous effect handlers. In other words, I added some tools that allow us to deal with asynchronous handlers in general, instead of Twisted handlers in particular.

Even the "parallel" effect is able to stay in effects core, while its gatherResults-based implementation is in effects.twisted -- by way of the separating the default dispatchers for "standard" effects code and "twisted" effects code. In order to make this simple to use, I added an 'effects.twisted.perform' top-level effect-performing function, which uses the twisted_dispatcher by default.

Since effect handlers are now forced to deal with a rather ugly asynchronous API, two new decorators have been added to make implementing effect handlers easier: @effect.synchronous_performer and @effect.twisted.deferred_performer. @synchronous_performer uses the return value of (or exception raised from) the function as the result to pass on to the next callback. @deferred_performer hooks up the Deferred to supply the result to the next callback.

(oh yeah, and I moved effect.Effect.perform to a toplevel function, effect.perform, along with a lot of other functions).


I've been thinking about this, and I'm really unhappy about the extra burden being put on effect handlers now.

After mulling it over I think we can get rid of the decorators, and go back to using the return value of the effect handler in all cases. We can keep the Twisted support separate by making twisted_dispatcher check if the result is a Deferred, and the default dispatcher would just use the normal result/exception.