Events refactor

[martyall]

This PR refactors the way the events coroutines are used and introduces breaking changes.

IMO there were always a few problems with the way that events were always set up:

1. using the filterId is dumb, it's sufficient to just use eth_getLogs if you know what you're doing. We already did this in hs-web3 when we decided we couldn't rely on being able to install filters on infura or even our own geth node (reliably).

2. The current coroutines library is limited in the kind of "middle" pipes you can make (between producer and consumer). It was impossible to do certain kinds of effectful processing in the middle. see this issue which inspired the coroutine-transducers library. NOTE: If we agree to merge this PR, I will move that over to a f-o-a-m repo.

3. In the event that a coroutine terminated early, you didn't necessarily know why. It could have been because the original filter only spanned blocks n to k and we are now on block k+1 so it's run its course. It could also be because the handler told you to TerminateEvent. With these changes you can tell because the coroutine will terminate by yielding a value of type

Either (FilterStreamState e) ChangeReceipt

where

type ChangeReceipt =
  { logIndex :: BigNumber
  , blockHash :: HexString
  , blockNumber :: BlockNumber
  , action :: EventAction
  }

Where Left will come from the filter running its course and Right will come from the event handler.

I have locally tested this against purescript-web3-tests, but havent pushed eveything because it's a big pain to do everything in unison. If we agree here, I will start to push everything.

[martyall]

NOTE: I'm still interested in getting the MultiFilter stuff in, but it would be easier to do it with these changes.

[martyall]

closing in favor of #124