Proposal to solve the `EitherT` problem.

[Gabriel Gonzalez]

As an application writer I'm a big fan of Edward's `either` package 
because his `EitherT` does not require an `Error` constraint.  As a 
library writer, I am wary of heavy dependencies and I would prefer 
something more light-weight that I can depend on.

Normally I would just directly contact Edward about reducing the number 
of dependencies but there was a previous discussion here about possibly 
merging his work into `transformers`, so I'm renewing that discussion 
and bringing up a few approaches for consideration.

There are three approaches that I'd like to submit for consideration and 
receive feedback on:

* Approach 1: Remove the `Error` constraint from `transformers`

Disadvantage: This silently breaks all existing uses of `fail`.  I don't 
know any way to add a compiler warning to notify downstream libraries of 
this change.

* Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and 
have them both implement `MonadError`.

Disadvantage: Bloat from having two almost identical monad 
transformers.  However, there is precedent from duplicating `StateT`, 
`WriterT` and `RWST` for both strict and lazy instances.

* Approach 3: Convince Edward to reduce the dependencies of the `either` 
package and submit the simplified version to the Haskell platform.

Disadvantage: One extra import instead of just importing `transformers`.

* Approach 4: None of the above.

Disadvantage: Packages that depend on `either` have very low prospects 
of making it into the Haskell platform.

If you have time, just take a moment to vote on which approach you favor 
or propose another alternative if you have another idea that I haven't 
listed.