Lots of changes:

    - When possible, we use the container infrastructure (sudo: false)
      rather than Google Compute Engine infrastructure (sudo: required).
      Unfortunately, we can't use GCE for the Linux builds, where
      reduced RAM available hoses are GHC build.

    - Switched from using ./Setup and old-style cabal to new-build.
      There are numerous great benefits but the best is that
      .cabal/store can be cached on Travis, leading to huge speedups
      on the build.  Downside is we need to string-and-ceiling-wax
      support for test/haddock/etc.

    - I stopped bootstrapping on every build we do; instead there
      is a separate bootstrap build we do to make sure that that
      is working.  This also speeds up the basic builds since
      we are not building Cabal/cabal-install multiple times.

    - There are some hacks.  The big one is setting CABAL_BUILDDIR
      explicitly; this smooths over quite a few infelicities in
      the current new-build implementation.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

See also #3528.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

The main point is solver packages don't HasUnitId; now that the
solver install plan is separate from install plan the knock-on
changes are quite localized and pleasing.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This is a bit more accurate and doesn't require any
fake UnitIds anymore. (But to-do: axe fake UnitIds!)

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

cabal-install still broken, but less so!

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Critically, InstallPlan no longer levies solver-style sanity checks
(e.g., whether or not the packages are consistent); it's assumed
the SolverInstallPlan checks this, and that processing an InstallPlan
is unlikely to cause problems here.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Now we monomorphize SolverInstallPlan so that its data structures
are non-parametric, and delete functions that are not needed.
Specifically:

    - GenericPlanPackage -> SolverPlanPackage, lose the
      type parameters, lose the Processing/Installed/Failed
      constructors (this makes some partial functions total! Yay!)

    - GenericInstallPlan -> SolverInstallPlan

    - PlanProblem -> SolverPlanProblem

    - Deleted ready, processing, completed, failed,
      preexisting

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Now we copy-paste the contents of InstallPlan into SolverInstallPlan,
thus giving it a separate set of types.  For now, we don't do anything
else, e.g., remove unnecessary functions or specialize.

We need a new function 'fromSolverInstallPlan' akin to
'mapPreservingGraph' which can take an InstallPlan from the
old solver install plan to the new one.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This is a preparatory commit for giving SolverInstallPlan
its own type.  We first start by moving the type synonyms
for SolverInstallPlan into their own module, and update
module references to point to them.

TODO: Maybe this module should go in the Solver hierarchy
rather than the client hierarchy?

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

[ci skip]

Looks like GitHub can't grok ed25519 or something.

I suspect that that's what's causing push failures.

[ci skip]

Try to install ghc manually on osx

[ci skip]