Excluded fields that make sense as command line flags but do
not make sense to use every time by saving in the config file.

At the request of Bjorn.

I can only trace the history back to the 0.3 era.

Was previously only available in the config file.

So it looks like:
install-dirs user
  prefix: /home/username/.cabal
  ...
Rather than using user-prefix, global-prefix, etc etc for each
field. The old field names are still recognised but not added
into the initial config file.

The user install setting selects between the two sets of dirs.
At the moment it's just the "user-" and "global-" prefixed field
names to support existing config files.

The intention here is to have the config file content and parser
be derivied from the command line types and flags. Now instead
of having a saved config type that contains additional
information to that kept in command line parameters we now put
all the information in the command line settings type and make
the saved config just the aggregation of the settings for
various key commands like configure, install, upload. There's
also an extended GlobalFlags type with the things like repos,
cache dir etc. When we generate the initial config file we put
in commented out versions of all (non-deprecated) valid fields,
along with their default values. The aim is to make the config
file self-documenting.

report and fix from Nicolas Frisby <nicolas.frisby@gmail.com>
(code had changed slightly so the original patch didn't apply cleanly)

Not just if the user specified -v or --dry-run. Otherwise
it's rather confusing. Also clarify that the reason there
is nothing to install is because the latest versions are
installed already. Also mention the --reinstall flag:
  Resolving dependencies...
  No packages to be installed. All the requested packages
  are already installed. If you want to reinstall anyway
  then use the --reinstall flag.

to force reinstall of package where we have the exact same
version already installed. Ordinarily we would say that
there is nothing to do as the exact same package version
is already installed. There are some cases where you might
want to do this, eg to rebuild with different compiler
options, or adding/removing components (since we do not
track those indifidually yet, eg docs, profiling libs).

Though obviously not if they have already been fetched.
This lets people study the source for core packages that
came with their compiler say, so they did not get have the
sources downloaded via cabal-install. Fixes ticket #297.

It just means we leave a temp file around in the bin dir.

This is a fairly heavyweight solution, but then it's quite
a nasty problem. What we do is when we notice that we're
about to install something in place of our own .exe file,
we move our exe file out of the way (but in the same dir).
Then after we've installed the new exe we call it and ask
it to delete the old file (so we do not litter the bin dir
with lots of old versions). That requires synchronising
between the old and new programs and for the new program
to understand a command to do the syncing and deleting of
the old program. Lots of Win32 FFI imports. :-(
On the plus side it seems to work and is transparent to
the user and the rest of cabal-install. In particular the
actual file-installation code (which is burried deep
within Cabal) does not need to know about the special case
of installing over our own exe file.

I hateses #ifdefs

Rather than the GenericPackageDescription.

It doesn't need access to the whole Packagedescription,
it only needs the the PackageIdentifier.

This addresses most of ticket #206.