Fixes a bug reported by Lennart Augustsson, whereby we could get an
incorrect error from the RTS about re-entry from a finalizer,

In GHC 6.10, intersectionWith is (a -> b -> a) instead of (a -> b -> c),
so we need to jump through some hoops to get the more general type.

...in the unusual case where they have one; 
see Note [Case binders and join points] in Simplify.lhs

The original interfaces are kept. There is small performance improvement:
- when compiling for five nofib, we get following speedups:
    Average                -----           -2.5%
    Average                -----           -0.6%
    Average                -----           -0.5%
    Average                -----           -5.5%
    Average                -----          -10.3%
- when compiling HPC ten times, we get:
    switches                          oldmaps   newmaps
    -O -fasm                          117.402s  116.081s (98.87%)
    -O -fasm -fregs-graph             119.993s  118.735s (98.95%)
    -O -fasm -fregs-iterative         120.191s  118.607s (98.68%)

This is a long-standing lurking bug. See Note [Lamba-bound unfoldings]
in DmdAnal.

I'm still not really happy with this lambda-bound-unfolding stuff.

The new Makefile logic was enabling the stage 1 rules when stage=2,
so "make 2" was rebuilding stage 1.

If the command line contains any Haskell source files, then we behave
as if --make had been given.

The meaning of the -c flag has changed (back): -c now selects one-shot
compilation, but stops before linking.  However, to retain backwards
compatibility, -c is still allowed with --make, and means the same as
--make -no-link.  The -no-link flag has been un-deprecated.

-fno-code is now allowed with --make (#3783); the fact that it was
disabled before was largely accidental, it seems.  We also had some
regressions in this area: it seems that -fno-code was causing a .hc
file to be emitted in certain cases.  I've tidied up the code, there
was no need for -fno-code to be a "mode" flag, as far as I can tell.

-fno-code does not emit interface files, nor does it do recompilation
checking, as suggested in #3783.  This would make Haddock emit
interface files, for example, and I'm fairly sure we don't want to do
that.  Compiling with -fno-code is pretty quick anyway, perhaps we can
get away without recompilation checking.

In particular, this fixes a problem where stage3 bits weren't being cleaned

We weren't getting sharedlibs on amd64/FreeBSD because of this

Noticed by Denys Rtveliashvili <rtvd@mac.com>, see #4004

Our END block was calling system, which alters $?. So now we save and
restore it.

This patch also fixes ullong_format_string (renamed to showStgWord64)
so that it works with values outside the 32bit range (trac #3979), and
simplifies the without-commas case.

Avoid using seq, as FreeBSD has jot instead.

The tso->block_info field is now overwritten by pushOnRunQueue(), but
stg_block_async_info was assuming that it still held a pointer to the
StgAsyncIOResult.  We must therefore save this value somewhere safe
before putting the TSO on the run queue.

I once saw a failure that I think was due to a race on
io_manager_event, this should fix it.

Some of the problems highlighted in trac #3968.

I was assuming that the unifer only unified types of the 
same kind, but now we can "defer" unsolved constraints that
invariant no longer holds.  Or at least is's more complicated
to ensure.  

This patch takes the path of not assuming the invariant, which
is simpler and more robust.  See
Note [Mismatched type lists and application decomposition]

In fixing this I did the usual little bit of refactoring

This stops us having to worry about sh/sed/... portability.