Add a fast version of the testsuite

The idea is to have a way to run as much of the testsuite as possible
in a short time, so that we'll run it more often (such as just before
checking in a change, for example).  'make fast' tries for good
coverage without using too many cycles.  Currently it takes about 4
minutes on a fast machine with an optimised GHC build; I think this
might still be a little on the slow side.

When you say 'make fast' in testsuite/tests/ghc-regress, we run each
test only one way, and all of the long-running tests are omitted.
Also, to get the runtime down further, I arbitrarily omitted many of
the should_run tests (because these tend to take a lot longer than
should_compile or should_fail tests).  I tried to keep a
representative few in each category.

Add deriving for infix constructors

mark GHC-specific tests

Add test for Show on unboxed types

Add unbox-strict-fields test

Add deriving test for record fields with leading underscore

Fails with 5.02.3

Add a new deriving test

Add another read/show test, on records

A read/show test involving Maybe

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.

Add deriving record show test

Add an array read and show test

Update expected results

Knock this into slightly better shape and bring over some more tests
from the old test suite.

Rename some functions used in vanilla-test.T to be more consistent/logical.

Add deriving/ tests.