simplifying user hooks (non-backward-compatible)

[Isaac Jones]

Following up on this thread...

I modified the hooks interface quite a bit, again.  There's good news
and bad news about this.  The good news is that it's cleaned up and
should be easier to maintain and to avoid future modifications.  The
bad news is that this change itself will break stuff, of course.

If you have any trouble building your Setup scripts, please let me
know.  I really think that it was best to bite the bullet right now in
one big go instead of down the road with lots of little changes.  I
have a lot more confidence in the hooks interface, and I don't
actually expect that it'll change as often.

I made the types more consistent, and made sure there are accessor
functions on each of the Flags types so that if the flags types change
in the future, it shouldn't break lots of code.

Another piece of good / bad news is that I decided not to get rid of
the pre & post hooks.  They are nice for convenience and it wouldn't
be nearly so easy to write hooks without them.

That's bad because the interface to hooks is still pretty big, which
means that there's more likelihood that it'll change in the future.

Another weakness in the Hooks interface is that with command hooks
(like sDistHook) it's tempting to add parameters to them; basically
the stuff that we compute between the preSDist and sDist hook.  I
removed such params and have their values computed elsewhere.

Cabal hackers, please avoid adding parameters to these command hooks
if at all possible in order to keep the interface steady.  If you need
to compute a value to pass to these functions, compute it in the
function and / or make it available as a function that someone
crafting hooks can use as well, or consider whether it belongs in one
of the parameters already being passed to the hooks,
PackageDescription, LocalBuildInfo, UserHooks, Flags.

throwing myself on your mercy,

  isaac