We want the universal and existential tyvars of a data constructor to
have distinct OccNames.  It's confusing if they don't (in error messages,
for example), and with the current way of generating IfaceSyn, it actally
generates bogus interface files.  (Which bit Roman.)

When IfaceSyn is full of Names, this won't matter so much, but it still
seems cleaner.

This patch adds a 'tidy' step to the generation of DataCon type 
variables in TcTyClDecls.tcResultType 

This is part 2 of the patch that improved the interaction of RULES and
recursion.  It's vital that all Ids that may be referred to from later in
the module are marked 'IAmALoopBreaker' because otherwise we may do
postInlineUnconditionally, and lose the binding altogether. 

So I've added a boolean rules-only flag to IAmALoopBreaker.  Now we can
do inlining for rules-only loop-breakers. 

Note [Case of cast]
~~~~~~~~~~~~~~~~~~~
Consider 	case (v `cast` co) of x { I# ->
		... (case (v `cast` co) of {...}) ...
We'd like to eliminate the inner case.  We can get this neatly by 
arranging that inside the outer case we add the unfolding
	v |-> x `cast` (sym co)
to v.  Then we should inline v at the inner case, cancel the casts, 
and away we go
	
This patch does the job, fixing a performance hole reported by Roman.

See Trac #683

This patch improves the interaction of recursion and RULES; at least I
hope it does.   The problem was that a RULE was being treated uniformly like
an "extra RHS". This worked badly when you have a non-recursive definition
that is made recursive only by RULE.

This patch maeks the occurrence analyser know whether a binder is referred to
only from RULES (the RulesOnly constructor in OccInfo).  Then we can ignore
such edges when deciding on the order of bindings in a letrec, and when
setting the LoopBreaker flag.

The remaining potential problem is this:
	rec{ f = ...g...
	   ; g = ...f...
	     RULE g True = ...
	   }

The RULE for g may not be visible in f's rhs.  This is fixable, but not
today.

I had forgotten to bring scoped type variables into scope at an expression
type signature, such as
	e :: forall s. <type>
where 's' should scope over the expression e.

Like everything to do with scoped type variables, fixing this took an 
unreasonable amount of work.  I'm sure there must be a better way to 
achitect this!

I updated the user manual too.

A test is tc213.

It would be good to push this into 6.6.1

Fixes Trac #919

Before the coKindFun could be applied to too many arguments;
now it expects exactly the right number of arguments.  That
makes it easier to write the coKindFuns, and localises the work.

Linear implicit parameters have been in GHC quite a while,
but we decided they were a mis-feature and scheduled them for
removal.  This patch does the job.

Without jumping to line numbers or %-expansion, we could add that later.

Addresses ticket #197, which asks for escape sequences to be supported directly (i.e.
not only in dquoted strings) on :load commands in GHCI.  Fix modifies the toArgs
function to parse its input like /bin/sh does, i.e. recognizing escapes anywhere
and treating quoted strings as atomic chunks.  Thus:
  :load a\ b c\"d e" "f
would parse with three arguments, namely 'a b', 'c"d', and 'e f'.

toArgs is used to parse arguments for both :load and :main, but doesn't appear to
be used elsewhere.  I see no harm in modifying both to be consistent -- in fact,
the functionality is probably more useful for :main than for :load.

We were assuming we could multiply 2 32-bit numbers without overflowing
a 64-bit number, but we can't as the top bit is the sign bit.