Note [Primop wrappers]

To support (limited) use of primops in GHCi genprimopcode generates the
GHC.PrimopWrappers module. This module contains a "primop wrapper"
binding for each primop. These are standard Haskell functions mirroring the
types of the primops they wrap. For instance, in the case of plusInt# we would
have:

    module GHC.PrimopWrappers where
    import GHC.Prim as P

    plusInt# :: Int# -> Int# -> Int#
    plusInt# a b = P.plusInt# a b

The Id for the wrapper of a primop can be found using
'GHC.Builtin.PrimOps.primOpWrapperId'. However, GHCi does not use this mechanism
to link primops; it rather does a rather hacky symbol lookup (see
GHC.ByteCode.Linker.primopToCLabel). TODO: Perhaps this should be changed?

Note that these wrappers aren't *quite* as expressive as their unwrapped
brethren, in that they may exhibit less representation polymorphism.
For instance, consider the case of mkWeakNoFinalizer#, which has type:

    mkWeakNoFinalizer# :: forall (r :: RuntimeRep) (k :: TYPE r) (v :: Type).
                          k -> v
                       -> State# RealWorld
                       -> (# State# RealWorld, Weak# v #)

Naively we could generate a wrapper of the form,


    mkWeakNoFinalizer# k v s = GHC.Prim.mkWeakNoFinalizer# k v s

However, this would require that 'k' bind the representation-polymorphic key,
which is disallowed by our representation polymorphism validity checks
(see Note [Representation polymorphism invariants] in GHC.Core).
Consequently, we give the wrapper the simpler, less polymorphic type

    mkWeakNoFinalizer# :: forall (k :: Type) (v :: Type).
                          k -> v
                       -> State# RealWorld
                       -> (# State# RealWorld, Weak# v #)

This simplification tends to be good enough for GHCi uses given that there are
few representation-polymorphic primops, and we do little simplification
on interpreted code anyways.

TODO: This behavior is actually wrong; a program becomes ill-typed upon
replacing a real primop occurrence with one of its wrapper due to the fact that
the former has an additional type binder. Hmmm....