'MSpec' was an existential in 'm', but I want to construct another
type which has both an 'MSpec' and some other 'm'-related fields. So I
am exposing the 'm' in 'MSpec' and creating another existential which
abstracts over it.

I want to reuse them

To make sure that the all the effects performed while releasing a
resource are preserved, not just the IO effects.

I'm writing the tests first, so the tests currently fail.

It is easy to accidentally implement the 'ExceptT' instance in a way
which causes the error message thrown during 'use' to get propagated
instead of the one thrown by 'release'. When both 'use' and 'release'
throw an IO exception, the one thrown by 'release' wins, so I think we
should follow suit.

Now that we have documentation for individual instances, there is no
need to repeat this seldom-used information here.

The exceptions package used to have an undocumented advantage over
lifted-base, namely that the non-IO effects are not discarded, but
then exceptions-0.9.0 made a breaking change which lost this
advantage. In this PR, I am restoring this advantage, and I am
documenting it, both to help users decide which package to pick, and
so we don't foolishly repeat that mistake.

This is the PR's main change. I make the type of 'generalBracket' even
more general, which allows me to fix the implementations of 'StateT'
and 'WriterT' so they don't discard their state changes.

if ExceptT has one, MaybeT should have one too

Update the documentation to reflect the difference between an
exception and an error, calling out the cases in which the user might
expect to catch all errors but will only catch all exceptions.

In particular, 'onException' will only run the handler when an
exception is thrown but not when any other kind of error is thrown;
this is not particularly useful, but we can't do better without
changing its type signature. A new function 'onError' is introduced
which does not have this flaw.

to match the style of the existing codebase

…and throwM.

the Either instance has one, so MaybeT and ExceptT should have one as well

to match the order in which the actions will be executed, like in
generalBracket.