Closes #202.

Now you can write onFoo **> effect to evaluate an effect every time an event is emitted. The syntax is inspired by Cats *> aka productR i.e. a flatMap that ignores the result of the left-side.

I worry that this syntax obfuscates an important detail, that is clearer when working with a stream with the --> syntax. Specifically, that until effect completes, handling of additional events will be blocked. So effect should not be a long-running task; instead, long-running tasks should be scheduled on some Supervisor.

Of course, to avoid this surprise, we could have **> always run effect on its own fiber to avoid blocking handling of additional events. I'd prefer not to do this by default, because:

1. the overhead of starting a fiber for each effect
2. the overhead of setting up a Supervisor for each **>
3. it makes it easy to start an unbounded number of tasks. In general, long-running tasks should be carefully managed, and requiring the user to set up a Supervisor or similar makes that management explicit.

Thoughts? :)