Fix -dynamic-too on Windows

If we're building the dynamic way too, then hasCafRefs needs to check
whether the dynamic way would use a dynamic name.
Simplify kind generalisation, and fix Trac #7916

A buglet that exposed an opportunity for some welcome refactoring
and simplification.  Main changes

* TcMType.zonkQuantifiedTyVars is replaced by quantifyTyVars, which
  does a bit more zonking (so that its clients do not need to)

* TcHsType.kindGeneralise becomes a bit simpler, and hands off
  to quantifyTyVars

* A bit of simplification of the hacky code in TcTyClsDcls.tcConDecl,
  where we figure out how to generalise the data constructor's type

* Improve the error message from badExistential when a constructor
  has an existential type, by printing the offending type

* Some consequential simplification in simplifyInfer.
fix comment (#7907)
Fix a problem caused by very large objects (#7919)

As far as I can tell the bug should be harmless, apart from the
failing assertion.  Since the ticket reported crashes, there might be
problems elsewhere that aren't triggered by this test case.
Handle -opt<blah> options more consistently (#7909)

Now these are always added by the run<blah> functions in SysTools, so
we never miss any out.  Several cleanups resulted.
Make AutoDeriveTypeable derive Typeable instances for promoted data constructors
Fix #5863
Wibbles to yesterday's "Simplify kind generalisation" patch

In particular, in mkExport we must quantify over the kind
variables mentioned in the kinds of the free type variables
Comment typo
Fix crash with large objects (#7919)

See comments for details.
Add an echo target to the build system
Revert "Fix -dynamic-too on Windows"

This reverts commit 5734f7afcc2b9acf857f8e0f745185bf01b91148.

It didn't fully fix -dynamic-too on Windows
Don't try to use -dynamic-too on Windows

It doesn't work
Accept derived Read on an empty data type (Trac #7931)
Do not do an ambiguity check on the type in a GHCi ":kind" command

Otherwise we get errors for polykinded type families;
   type family F a :: *
Then :k F
would give an ambiguity check trying to unify (F k1) with (F k2),
which is all a bit stupid.

I found this when investigating Trac #7939
Print kinds of non-* tyvar binders in pprTyThing

This makes the output of :info more useful
Give 'unboundName' a very low binding precedence

This fixes Trac #7937
Check for illegal syntax in types (fixes Trac #7943)
Make 'SPECIALISE instance' work again

This is a long-standing regression (Trac #7797), which meant that in
particular the Eq [Char] instance does not get specialised.
(The *methods* do, but the dictionary itself doesn't.)  So when you
call a function
     f :: Eq a => blah
on a string type (ie a=[Char]), 7.6 passes a dictionary of un-specialised
methods.

This only matters when calling an overloaded function from a
specialised context, but that does matter in some programs.  I
remember (though I cannot find the details) that Nick Frisby discovered
this to be the source of some pretty solid performanc regresisons.

Anyway it works now. The key change is that a DFunUnfolding now takes
a form that is both simpler than before (the DFunArg type is eliminated)
and more general:

data Unfolding
  = ...
  | DFunUnfolding {     -- The Unfolding of a DFunId
    			-- See Note [DFun unfoldings]
      		  	--     df = /\a1..am. \d1..dn. MkD t1 .. tk
                        --                                 (op1 a1..am d1..dn)
     		      	--     	    	      	       	   (op2 a1..am d1..dn)
        df_bndrs :: [Var],      -- The bound variables [a1..m],[d1..dn]
        df_con   :: DataCon,    -- The dictionary data constructor (never a newtype datacon)
        df_args  :: [CoreExpr]  -- Args of the data con: types, superclasses and methods,
    }                           -- in positional order

That in turn allowed me to re-enable the DFunUnfolding specialisation in
DsBinds.  Lots of details here in TcInstDcls:
	  Note [SPECIALISE instance pragmas]

I also did some refactoring, in particular to pass the InScopeSet to
exprIsConApp_maybe (which in turn means it has to go to a RuleFun).

NB: Interface file format has changed!
Refine 'type_determines_value' in Specialise.  Fix Trac #7785.

See Note [Type determines value] in Specialise.