inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure

(Imported from [Trac #458](http://hackage.haskell.org/trac/hackage/ticket/458), reported by @dcoutts on 2009-01-16)

We have a mismatch between the cabal Setup scripts which ignore LDFLAGS etc and provide --extra-lib-dirs instead, and some ./configure scripts which grab the CCFLAGS etc and bung them into a .buildinfo file.

This is bad because it means --extra-lib-dirs does not work for those packages and it also means that those packages consult the CCFLAGS etc and others do not. It's quite an inconsistent user interface.

We should try to make it more consistent. One approach would be for cabal to consider the CCFLAGS etc, to combine them with the flags passed on the command line and those specified in the .cabal file. (We have code to analyse CC/LD/CPP flags and to split them up into the standard `BuildInfo?` fields.) Then for configure scripts we could pass the whole lot. The danger of course is that the configure scripts duplicate it all and put it into a .buildinfo file.

Another tempting option is to call configure with a clean environment so that it cannot pick up these vars. Unfortunately that might break some existing packages.

We should be careful with the use of these env vars though, because while it's fine to change the user interface to cabal-install, the interface to the Setup.hs is a machine interface and the more we require of it, the more has to be implemented by every different build system.

A case in point is the curl package. It has a .buildinfo file like:

cc-options: @CPPFLAGS@

ld-options: @LDFLAGS@

The ./configure script checks:

AC_TRY_CPP([#include <curl/curl.h>],,[no_curl=yes])

Which uses the CPPFLAGS.

So it's adding an extra package-specific user interface by consulting these environment variables. At the same time the configure script ignores the --extra-lib-dirs= and --extra-include-dirs= Setup.hs command line flags. This means that users doing what is advertised will find the package does not work. Indeed changing to build-type: Simple and deleting the configure script makes it work perfectly. So this mismatch is clearly harmful.

See also #262 which should make these checks redundant.