TODO: This seems to cause Windows failure

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

Previously, in some cases we would carry around an explicit
FilePath for an executable that we wanted to invoke subsequently.

In this new scheme, any executable we want to execute gets registered
to the ProgramDb we are carrying around.  Now we can uniformly
use runProgramM in all cases.  Great!

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

This is a pretty important new feature in the test suite, which
is to construct a remote repository on the fly as part of the
test suite.

The general principle is that you create a directory full of folders
for all of the packages you want available in the repo, and then
the 'withRepo' function will initialize this into a secure repo
you can do tests with.

Fixes #4016.

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>

A bit of trickiness here.  The high points:

    - We need to feed --with-compiler to cabal.config, NOT
      the flag, because sandbox doesn't know how to read in
      compilers except from the global config.  This is
      arguably a bug but I can't be bothered to fix it.

    - We need to NOT provide certain commands when we're
      in sandbox mode; this is controlled by testHaveSandbox.

    - Use withSandbox to start a session in the sandbox.
      It inits the sandbox for you.

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>

This information is useful for determining where the build products
are placed, so we can, e.g., run the built executables.

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

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

See cabal-testsuite/README.md for a detailed description
of the new architecture.

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