Now it searhes for *.cabal in the current directory, if it finds more
than one, there's an error.  For now, it allows Setup.description with
a warning.

When building executables, one typically wants to build them based on
the library that's contained in the cabal package.  This was difficult
if both the executables and the library used different
hs-source-dir's.  This patch causes executables to look at the
library's hs-source-dir for modules when preprocessing and building.

This is instead of building and locally installing a package and using
the -package flag to build the executable, since that's more
complicated, and won't necessarily work if the library isn't designed
to be installed in-place.

  I added getHomeDirectory function to Distribution.Compat.Directory
  which
  now is used from GHCPackageConfig.localPackageConfig instead of
  (getEnv "HOME").
  Without this fix the build process under Windows terminate with
  "does not exists (no environment variable)".
  
  NOTE: The fix works only if Cabal is built with ghc-6.3+. In any other case
  getHomeDirectory is defined as getEnv "HOME" and will continue to fail.
  This can be fixed but it will add an additional dependency of Cabal from
  shell32 under Windows and ghc < 6.3. I decided to leave the things at this
  stage because they are more maintainable in this way. If this is a pain I
  can rewrite the things latter.

It's pretty common to have a situation where two modules with
different filenames are both named Main.  If they're in the same
directory, and we use the -odir and -hidir flags, ghc --make uses the
Main.o produced from the first build to link the 2nd!

I added a pretty tricky test case for this, after it was reported by
Ganes Sittampalam while trying to build the HaXmL executables.

I fixed it today by adding the executable name to the -odir and -hidir
paths, to make sure that they don't use the same Main.o... this is a
bit inefficient, though, because I'm pretty sure that means it will
rebuild any bits of the library it depends on for each executable.

Any objections to this?

Two of the bugs were passing the wrong accessor function to the pretty
printer.

The third bug was that the pretty printer rendered "foo\\bar" as
"foo\bar", but actually in order to get the slash into the string, the
user would have to have used the quote syntax.  I think we decided
that the quote syntax meant a haskell string, so they should input it
as "foo\\bar", of course internally represented as "foo\bar', but when
printed, it should show two slashes again.

  buildHugs: use lex to tokenize the source file when looking for "foreign"
  use FilePath.objExtension
  only read Setup.buildinfo if present
  trim "Multi-line!" from help message
  move hcOptions function to Distribution.PackageDescription
  add Hugs options and $@ to runhugs command line (Unix only)

Long story:

It seems that Marvin removed my beautiful and powerful "getOpt"
alterations to use the System.Console one, which I had already deemed
to be non-beautiful because of the errors it spews when faced with
arguments it doesn't understand.

I think Marvin misunderstood the API docs that seem to suggest that
the "commands" that get passed back from getOpt are the non-matched
arguments.  In fact, non-matched arguments get returned as errors
(ewwwww).

So I had to re-apply my GetOpt module, and alter the parser
accordingly.

Also, since it's not OK to pass random arguments all the time (just
when you have user hooks), I cleaned up calls to no_extra_flags to
only get called when there's nothing sensible to do with unknown
arguments.

** The value of --copy-prefix is now prepended to that of --prefix
(like $DESTDIR) instead of replacing it.  As Ross pointed out, it
doesn't really make sense for --prefix not to be a prefix of
--copy-prefix, as the value of --prefix may be embedded in the
generated files.

** Unit tests change to reflect

** add a newline to the end of the installed package description
** When pretty-printing free-format text fields, align the lines vertically
  (so that following lines will be seen as continuations) and replace empty
  lines with "." (so they'll be correctly re-parsed, instead of looking
  like a stanza separator).

First cut at installHugs.  The treatment of executables is still incomplete.
simplistic register/unregister for Hugs:
  
  * register copies the installed package decsription into the packages dir
  
  * unregister uninstalls the package
Hugs supports FFI without extra flags