Reimplemented and documented dire.test.simulate

The processing of every event needs now to be confirmed before
the next event is being fired. This gives much more control over
when a new event is fired. For instance, in a swing-based user interface
just wait until the UI itself has been updated. The rest of the
reactive graph will have followed.
Removed usage of scalaz.concurrent.Strategy.SwingStrategy

The usage of this strategy could lead to deadlocks when shutting
down a reactive system from within the EventDispatchThread.
Judicious usage of scalaz.concurrent.Strategy

Letting clients decide what strategy to use in parts of a
signal function grants flexibility at the risk of broken code.
Therefore, former functions like sfIO or connectOuts (both now
private) as well as factories for data sinks no longer take
an optional Strategy argument. These functions now come in two
forms: synchronous (the IO action block the reactor's main thread)
and asynchronous (the IO action runs on a separate thread of the
reactive system). For most use cases this should be enough.

The problems with user-defined strategies first came up when
trying to shutdown a reactive system from within Swing's
EventDispatchThread. Some of the actors in the reactive system
used the EventDispatchThread to run their actions and could
therefore not be killed (=> deadlock).

The strategy for the above use case (Swing guis) is now to instead of
using scalaz.concurrent.Strategy.SwingDispatch, using functions
scala.swing.swingOut and scala.swing.swingSink which only run the
IO actions on the EventDispatchThread while using a sequential actor.
More logging in ReactiveSystem