lost in patch "Run sparks in batches"

Fixes "invalid what_next field" in ioref001 on Windows, and perhaps others

Signficantly reduces the overhead for par, which means that we can
make use of paralellism at a much finer granularity.

Fixes a bug whereby the Capability has been freed but other
Capabilities are still trying to steal sparks from its pool.

This is just good practice to avoid placing two structures heavily
accessed by different CPUs on the same cache line

MERGE TO 6.10.

Following suggestions from users, this patch improves the error message
when a GADT match needs a rigid type:

 tcfail172.hs:19:10:
     GADT pattern match in non-rigid context for `Nil'
-      Solution: add a type signature
+      Probable solution: add a type signature for `is_normal'
     In the pattern: Nil
     In the definition of `is_normal': is_normal Nil = True

Now GHC tries to tell you what to give a type signature *for*.
Thanks to Daniel Gorin and others for the suggestions.

This patch, written by Max Bolingbroke,  does two things

1.  It adds a new CoreM monad (defined in simplCore/CoreMonad),
    which is used as the top-level monad for all the Core-to-Core
    transformations (starting at SimplCore).  It supports
       * I/O (for debug printing)
       * Unique supply
       * Statistics gathering
       * Access to the HscEnv, RuleBase, Annotations, Module
    The patch therefore refactors the top "skin" of every Core-to-Core
    pass, but does not change their functionality.

2.  It adds a completely new facility to GHC: Core "annotations".
    The idea is that you can say
       {#- ANN foo (Just "Hello") #-}
    which adds the annotation (Just "Hello") to the top level function
    foo.  These annotations can be looked up in any Core-to-Core pass,
    and are persisted into interface files.  (Hence a Core-to-Core pass
    can also query the annotations of imported things.)  Furthermore,
    a Core-to-Core pass can add new annotations (eg strictness info)
    of its own, which can be queried by importing modules.

The design of the annotation system is somewhat in flux.  It's
designed to work with the (upcoming) dynamic plug-ins mechanism,
but is meanwhile independently useful.

Do not merge to 6.10!  

Up to now, the data constructor dictionary for class C as been called
":DC". But there is no reason for the colon to be at the front; indeed
it confuses the (simple-minded) pretty-printer for types.  So this
patch changes it to be "D:C".  This makes Core a lot easier to read.
Having a colon in the middle ensures that it can't clash with a user-written
data type.

Similarly I changed

  T:C 	   Data type corresponding a class dictionary (was :TC)
  D:C	   Data constructor for class dictionary (was :DC)

  NTCo:T   Coercion mapping from a newtype T to its representation type
		(was :CoT)

  TFCo:R   Coercion mapping from a data family to its respresentation type R
		(was :CoFR)

  Rn:T     The n'th respresentation data type for a data type T
		(was :RnT)


Do not merge to 6.10.

HEADS-UP: you'll need to recompile libraries from scratch.  

ROMAN: you could do the same for OccName.mkVectTyConOcc etc, if you wanted.

The issue here is what happens when we have

	(f |> co) x

where f is itself marked INLINE.  We want callSiteInline to "see" 
the fact that the function is applied, and hence have some incentive
to inline.  I've done this by extending CoreUnfold.CallCtxt with 
ValAppCtxt.  I think that should catch this case without messing up
any of the others.