This also includes modifications to the solver testing DSL and the
testing functions.

This is necessary for merging PR #2732.

Every package now "depends" on all language extensions
(default-extensions and other-extensions) and language flavours
(default-language and other-languages) it declares in its cabal file.

During solving, we verify that the compiler we use actually
supports selected extensions and languages. This has to be done
during solving, because flag choices can influence the declared
extensions and languages being used.

There currently is no equivalent check performed on the generated
install plans. In general, cabal-install performs a sanity check
on the solver output, checking that the solver e.g. indeed includes
all the declared dependencies of a package. There is no such
double-checking for language extensions. This is not really
problematic, as all that this change does is to make the solver
more conservative rather than less. However, having a sanity check
available might ultimately be nice to have.

Conditionally omit `TemplateHaskell` from set of supported extensions

This emulates what GHC>=8 will do on its own for older GHC versions.

This is particularly useful in combination with #2644 allowing the
solver to toggle flags depending on the availability of
`-XTemplateHaskell`.

For instance, cross-compilers and/or unregisterised GHC builds often
don't have TemplateHaskell support. Having support for toggling flags
based on availability of `-XTemplateHaskell` allows `cabal` to
support such environments with less manual intervention.

Teach Cabal about GHC's Strict language extension

Use `-fno-warn-implicit-prelude' in Paths_* module

When GHC is invoked with `-fwarn-implicit-prelude', then autogenerated
Paths_* modules are source of unnecessary warnings.

This commit adds OPTIONS_GHC pragma with `-fno-warn-implicit-prelude' in
to Paths_* module, so that such warnings are suppressed.

Some more IBM AIX fixes

Otherwise this emits linker flags not suitable for XCOFF

IBM AIX requires its own proprietary linker which does not support
`--strip-unneeded`.

The `Permissive` classification is for recognising tokens from the
"outside world". `platformFromTriple` is similar to
`buildOS`/`buildArch`.

Specifically, on IBM AIX, the platform triple is usually
"powerpc-ibm-aix", where "powerpc" will only be recognised in
`Permissive` mode.

Disable Ar.wipeMetadata for AIX

AIX uses its own `ar` format variant (with a different header),
which causes Cabal to abort with

  Distribution.Simple.Program.Ar.wipeMetadata: Bad global header

This patch simply disables this non-essential operation for AIX.

Global Constraints Option

Make `cabal init` reject extra arguments.

binary-0.8.0.0 will provide Binary Version

This is better than ignoring them because one is likely in some state of
confusion when passing extraneous arguments to `cabal init` and would
probably appreciate being taken out of that state sooner rather than
later.

Show details direct

This mode implements #2911, and allows to connect the test runner
directly to stdout/stdin. This is more reliable in the presence of no
threading, i.e. a work-arond for #2398.

I make the test suite use this, so that it passes again, despite
printing lots of stuff. Once #2398 is fixed properly, the test suite
should probably be extended to test all the various --show-details
modes.

Update Travis job to use GHC 7.10.3

Implement `cabal upload --doc`

The test case is changed to print a rather large amount of text, large
enough to fill a buffer. This way, the buffer draining functionality in
the test runner is tested, and it reveals #2398.

This makes the test suite currently fail, of course, but the bug was
there before.

This gives newcomers like me a better chance to understand how the Cabal
test suite is constructed.

The powershell script contains the password, so writing it to a file
is a bit unsafe. We know pass it via stdin.
This commit also improves the error message for network failures a
little bit.

Passing passwords via command line arguments is insecure: anyone who
is able to read the process list on the system can read the passwords
as well.

For curl, we pass the password via stdin by using the --config option,
which allows us to pass arbitrary additional options via stdin.

Unfortunately, wget's --config option does not support - for stdin. So
we instead use the --input-file option to pass an URI with the password
via stdin.

Bench.hs: use exitSuccess and forM

Solver: limit where package target constraints apply

When we have a target like "foo-1.0", in terms of solver input this
gets turned into a target package name of "foo" and a (labelled)
constraint of "foo == 1.0". This constraint is of course to ensure
that we pick the right target. However, with the recent addition of
qualified package goals we have the possibility of picking multiple
versions of the same package (e.g. via setup deps). If we have a
constraint like "foo == 1.0" apply everywhere then it becomes
impossible to pick multiple versions of package "foo", which may
mean we cannot find a solution at all. But the constraint for the
target need not apply everywhere, it's just to ensure that for the
"main" instance, we pick the right version.

This patch makes that precise. We have these constraints arising
from targets apply only to package name goals that are suitably
unqualified: qualifications arising from independent goals and from
base version trickery are ok, but qualifiactions from setup deps
are not. Or to put it another way, these target constraints do not
apply to goals arising as the result of setup dependencies.

As a more concrete example, this allows a situation where a package
needs an old version of Cabal as a setup dep, but a new version of
Cabal is also present in the main part of the solution as a normal
library dep. Whenever we solve for that main Cabal lib as a target
it would previously fail (it would be impossible to satisfy the
conflicting constraints on the Cabal setup dep) and it now works.

The only change between process 1.3 and 1.4 is:

"Added child_user and child_group to CreateProcess for unix. #45"

And the relevant code in Cabal doesn't seem affected by those additional
members.