contributed by Neil Mitchell <ndmitchell@gmail.com>, with docs by me.

this is so that the stage1 compiler has proper support for Unicode.
Should fix these errors:

  lexical error in string/character literal at character '\8759'

when building the stage2 compiler.

This relates to the recent introduction of clean/dirty TSOs, and the
consqeuent write barriers required.  We were missing some write
barriers in the takeMVar/putMVar family of primops, when performing
the take/put directly on another TSO.

Fixes #705, and probably some test failures.

Now that we can handle using C argument registers as global registers,
extend the x86_64 register mapping.  We now have 5 integer argument
registers, 4 float, and 2 double (all caller-saves).  This results in a
reasonable speedup on x86_64.

Eliminate things like "warning: call-clobbered register used as global
register variable", which is an non-suppressible warning from gcc.

The problem here was that we generated C calls with expressions
involving R1 etc. as parameters.  When some of the R registers are
also C argument registers, both GCC and the native code generator
generate incorrect code.  The hacky workaround is to assign
problematic arguments to temporaries first; fortunately this works
with both GCC and the NCG, but we have to be careful not to undo this
with later optimisations (see changes to CmmOpt).

We now have more stg_ap entry points: stg_ap_*_fast, which take
arguments in registers according to the platform calling convention.
This is faster if the function being called is evaluated and has the
right arity, which is the common case (see the eval/apply paper for
measurements).  

We still need the stg_ap_*_info entry points for stack-based
application, such as an overflows when a function is applied to too
many argumnets.  The stg_ap_*_fast functions actually just check for
an evaluated function, and if they don't find one, push the args on
the stack and invoke stg_ap_*_info.  (this might be slightly slower in
some cases, but not the common case).

fix one incorrect case, and made several more accurate

	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Simplfy (i.e. substitute) the IdInfo of a recursive group of Ids
before looking at the RHSs of *any* of them.  That way, the rules
are available throughout the letrec, which means we don't have to
be careful about function to put first.

Before, we just simplified the IdInfo of f before looking at f's RHS,
but that's not so good when f and g both have RULES, and both rules
mention the other.

This change makes things simpler, but shouldn't change performance.

The most likely cause is out-of-memory, not an RTS error.

This works around a problem with recent versions of GNU make that take
a long time when all targets are declared intermediate with
.SECONDARY.  See 

  https://savannah.gnu.org/bugs/?func=detailitem&item_id=15584

for discussion of the GNU make issue.

Fix previous patch "NCG: Handle loops in register allocator"
Of course, I broke it when correcting a style problem just before committing.

Fill in the missing parts in the register allocator so that it can
handle loops.

*) The register allocator now runs in the UniqSuppy monad, as it needs
   to be able to generate unique labels for fixup code blocks.

*) A few functions have been added to RegAllocInfo:
	mkRegRegMoveInstr -- generates a good old move instruction
	mkBranchInstr     -- used to be MachCodeGen.genBranch
	patchJump         -- Change the destination of a jump

*) The register allocator now makes sure that only one spill slot is used
   for each temporary, even if it is spilled and reloaded several times.
   This obviates the need for memory-to-memory moves in fixup code.

LIMITATIONS:

*) The case where the fixup code needs to cyclically permute a group of
   registers is currently unhandled. This will need more work once we come
   accross code where this actually happens.

*) Register allocation for code with loop is probably very inefficient
   (both at compile-time and at run-time).

*) We still cannot compile the RTS via NCG, for various other reasons.

This restructoring makes the renamed export and import lists
available in IDE mode.

We were searching the wrong part of the heap for dead objects, this
was broken by recent changes to the step structure: from-space is now
in step->old_blocks, not step->blocks.  Fortunately some assertions in
ProfHeap picked up the problem.

There was an integer overflow in the definition of LDV_RECORD_CREATE
when StgWord is 64 bits.