New interpreter based on conduits, though it's not working yet.
First approach is feasible.

As first approach, I've developed a terrible conduit interpreter. It
turns every action into a conduit and appends it to the
pipeline. As a result, we end up with an enormous pipe which is
employed just once. Why is it so terrible?

* All the actions (chunks) are kept in memory (once for each conduit).

* This is not incremental nor continuous. Just one pass? This is a
  joke for stream processing capabilities. We're not exploiting it.

* The way to implement Get and Put is quite interesting. We're
  attaching the next component at the end of the do-notation. This is
  really ugly and not very readable (lets are not allowed!).

* This won't adapt to a REST architecture. In that situation, we don't
  know the actions until we receive them!

On the other hand, there's one good point. Now we know we can develop
a conduit interpreter without using the state monad. This is just the
starting point to create a nicer one.
New conduit-interpreter approach, using actions as input.

Yet another interpreter, which is better than the previous one, but
still useless. Next, I'll show the benefits/drawbacks of this
approach:

+ It works
+ It's nice the way the result is generated (by the sink).
+ It's a proof that IORefs is as good as State for this concern.
+ We can keep the inner state at the sink.

- We haven't use any conduit. In fact, we use Source and Sinks in a
  forced manner, since they're unnecessary.
- The important task (keeping the next state) is achieved by the
  surrounding IORef.
- In theory, we could think that Actions are a good example of a
  chunk. In practice, with Free Monads application, this is impossible
  since we need the result of the previous actions to fulfill the rest
  of them (think of: ref <- Put "hola"; Get ref).
- The state is kept as a whole. This requires further researching, but
  I'm afraid it won't be easy to be splitted.
- Passing IORefs around is kind of ugly.
Merge pull request #83 from jeslg/conduit-interpreter

Conduit interpreter