The core type-matcher Unify.match was previouly using tcView to expand
types, because it must treat newtypes as distinct from their representation.
But that meant that it also treated the PredType {C Int} as distinct from
its representation type (:TC Int).  And that in turn was causing a rule
not to fire, because the argument types didn't match up.

For this to happen we need to get a situation where we have

  a = :DC blah blah	-- Dictionary
  ....(f a).....

Now a has type (:TC Int), bu the RULE for f expects an argument 
of type {C Int}.  Roman found that just this was happening.

I can't think how this one escaped for so long, but
	(error "foo") 
should have arityType ABot, just as 'error' itself does.

This improves eta expansion.  I spotted it when looking at the function

  Data.Array.Parallel.Arr.BBArr.writeMBB

in the ndp package.

We were making filenames like
dist/build/GHC/Base.p_.o
rather than
dist/build/GHC/Base.p_o

Split off a FastBool module, to avoid a circular import with Panic

Patch from Bertram Felgenhauer <int-e@gmx.de>

Fixes the build on OpenBSD (trac #2009). Based on a patch from kili.

Readline.initialize spills some escape sequences to stdout for some terminal
types, potentially spoiling  ghc -e  output. So don't initialize readline
unless we're working interactively on a terminal.
Patch from Bertram Felgenhauer <int-e@gmx.de>

The type checker doesn't support lexically scoped type variables 
unless we are using the RelaxedPolyRec option.  Reasons: see
Note [Scoped tyvars] in TcBinds.

So I've changed DynFlags to add this implication, improved the 
documentation, and simplified the code in TcBinds somewhat.
(It's longer but only because of comments!)
 

It controls the number of simplifier phases run during optimisation. These are
numbered from n to 1 (by default, n=2). Phase 0 is always run regardless of
this flag. The flag is ignored with -O0 since (practically) no optimisation is
performed in that case.

The float-out transformation must handle the case where a coercion
variable is free, which in turn mentions type variables in its kind.
Just like a term variable really.

I did a bit of refactoring at the same time.

Test is tc241

MERGE to stable branch

This patch (which is part of the fix for Trac #2018) makes coercion variables
be handled more uniformly.  Generally, they are treated like dictionaries
in the type checker, not like type variables, but in a couple of places we
were treating them like type variables.  Also when zonking we should use
zonkDictBndr not zonkIdBndr.