More flexible and based on the ProgramInvocation stuff

For tasks like registering where we call hc-pkg, this allows us to
produce a single program invocation and then either run it directly
or write it out as a script.

Close the input after pushing it. Return any error message.

Add an explicit intermediate ProgramInvocation data type.

It is a bad idea for clean to do anything different depending
on whether the package was configured already or not. The
actual cleaning code did not use the LocalBuildInfo so this
only changes in the UserHooks interface. No Setup.hs scripts
actually make of this parameter for the clean hook.
Part of ticket #133.

Since we now always have a GenericPackageDescription

Rather than Either GenericPackageDescription PackageDescription
In principle this is an interface change that could break Setup.hs
scripts but in practise the few scripts that use confHook just pass
the arguments through and so are not sensitve to the type change.

Also changes Simple.defaultMainNoRead to use GenericPackageDescription.
This is an API change that in principle could break Setup.hs scripts
but in practise there are no Setup.hs scripts that use either.

The arguments to isPrefixOf were the wrong way round. We want to see if
the line starts "\\begin{code}", not if the line is a prefix of that string.

Fixes ticket #435. This is an approximation. It will ban most
but not all cases where a package specifies no upper bound.
There should be no false positives however, that is cases that
really are always bounded above that the check flags up.
Doing a fully precise test needs a little more work.

Now requireProgram doesn't take a version range and does not check
the program version (indeed it doesn't need to have one). The new
function requireProgramVersion takes a required program version
range and returns the program version. Also update callers.
Also fixes the check that GHC has a version number.

Yes of course UTF8 text files should not use the BOM but
notepad.exe does anyway. Fixes ticket #533.

Fixes ticket #89. The library gets registered into an inplace
package db file which is used when building the executables.
Based partly on an original patch by Stephen Blackheath.

Since we have to be able to use these inplace we always need
the index it's not enough to just make the index on installing.
This particularly affects OSX.

Allow the user package db to appear after a specific one.
No reason not to and makes some things in cabal-install more convenient.

Part of #369

Just uses simplifyVersionRange on the version range in the dep

This lets us pass a whole stack of package databases to the compiler.
This is more flexible than passing just one and working out what
other dbs that implies. This also lets us us more than one specific
package db, which we need for the inplace package db use case.

Part of ticket #369. Now instead of:
  setup: At least the following dependencies are missing:
  base <3 && <4 && <3 && <3 && <4
we get:
  setup: At least the following dependencies are missing:
  base <3

Part of one of Stephen Blackheath's patches