threaded1 = -threaded -debug
threaded2 = -O -threaded, and +RTS -N2 -RTS at runtime

Add -dcmm-lint when compiling

- add SMP way for tests
- add RTS way flags: -N2 for SMP (test multi-processor), and -p for
  profiling (actually test the profiler!)

profasm way only if ghc_with_native_codegen.

add unreg & profasm ways

Add 'threaded' way to run tests with the threaded RTS.

Added support for testing generation and compilation of External Core
code. There are two new ways, which are not automatically enabled but can be
invoked from the command line: extcore and optextcore. Invoking either way will
test that ghc is able to generate External Core code for a given test, read the
code back in, and compile it to an executable that produces the expected output
for the test.

The External Core facility has a few limitations which result in certain tests
failing for the "extcore" way.
  - External Core can't represent foreign calls other than static C calls
  - External Core can't correctly represent literals resulting from a
    "foreign label" declaration
  - External Core can't represent declarations of datatypes with no
    constructors
The first of these was already known, and GHC panics if you tried to
generate External Core for a program containing such a call. The second two
cases were not handled properly before now; in another commit, I've changed the
code that emits External Core to panic if either of them arises. Previously,
GHC would happily generate External Core in either case, but would not be able
to compile the resulting code.

There are several tests that exhibit these limitations of External Core, so
they've had to be made "expected failures" when compiling in the extcore or
optextcore ways.

re-enable ghci tests

Disable GHCi tests for now, one of them is causing GHCi to go into a loop

oops, remove ghci from compile_ways

Add support for running tests with GHCi.  This is an additional "way"
in the test system, which is enabled automatically if
$(GhcWithInterpreter) = YES, and only applies to tests that run (as
opposed to tests that just compile).

- Move some of the way-selection logic into the configuration file;
  the build system now just passes in variables saying whether the
  compiler supports profiling and native code generation, and the
  configuration file adds the appropriate ways.

- Add a new option to the test driver, --way=<way> to select just a
  single way.

Don't enable the optasm way by default

Revamp the testsuite framework.  The previous framework was an
experiment that got a little out of control - a whole new language
with an interpreter written in Haskell was rather heavyweight and left
us with a maintenance problem.

So the new test driver is written in Python.  The downside is that you
need Python to run the testsuite, but we don't think that's too big a
problem since it only affects developers and Python installs pretty
easily onto everything these days.

Highlights:

  - 790 lines of Python, vs. 5300 lines of Haskell + 720 lines of
    <strange made-up language>.

  - the framework supports running tests in various "ways", which should
    catch more bugs.  By default, each test is run in three ways:
    normal, -O, and -O -fasm.  Additionally, if profiling libraries
    have been built, another way (-O -prof -auto-all) is added.  I plan
    to also add a 'GHCi' way.

    Running tests multiple ways has already shown up some new bugs!

  - documentation is in the README file and is somewhat improved.

  - the framework is rather less GHC-specific, and could without much
    difficulty be coaxed into using other compilers.  Most of the
    GHC-specificness is in a separate configuration file (config/ghc).

Things may need a while to settle down.  Expect some unexpected
failures.