* -{short,long}-ghci-banner are now dynamic options, so you can put
  ":set -short-ghci-banner" in .ghci
* The -v2 banner information now always tells you what compiler booted GHC,
  and what stage the compiler is. Thus we no longer assume that stage > 1
  iff GHCI is defined.

Add -short-ghci-banner and -long-ghci-banner.  The default is long, which is
the current behavior.  The short banner prints a one-line introduction with
only the version, web site, and ":? for help" message.

- parseStaticFlags is now not required, but if it is called, it should
  be called only once and before newSession, otherwise you get an
  error.
- parseStaticFlags is exported from GHC

Argubly rewrite rules should not fire with -O0, and it turns
out that when compiling GHC.Base with -O0 we get a crash if
the rewrite rules do fire (see Note [Scoping for Builtin rules]
in PrelRules).

So unless someone yells, rewrite rules are off with -O0.

The new (now dynamic) flag is 
    -frewrite rules (with -fno-rewrite-rules to disable)

The old (static) flag -frules-off is gone.

-ticky is the command-line flag for ticky-ticky profiling now, but
internally, the -fticky-ticky flag was used to represent whether ticky
was on. This led to link errors if the user supplied -fticky-ticky but
not -ticky (ticky code would be generated but the wrong RTS library
would be passed to the linker). I removed references to -fticky-ticky
-- now, only the way flags dictate whether ticky is on, and
-fticky-ticky is no longer accepted as a command-line option.

When a snapshot version number is included, opt_HiVersion tends to exceed the range of a 32bit Int.

MERGE TO STABLE

The ticky static flag was being poked too early, which lead to
breakage in the -prof way amongst other things.  I've installed some
sanity checking to make sure we catch this earlier if it happens again.

The following changes restore ticky-ticky profiling to functionality
from its formerly bit-rotted state. Sort of. (It got bit-rotted as part
of the switch to the C-- back-end.)

The way that ticky-ticky is supposed to work is documented in Section 5.7
of the GHC manual (though the manual doesn't mention that it hasn't worked
since sometime around 6.0, alas). Changes from this are as follows (which
I'll document on the wiki):

* In the past, you had to build all of the libraries with way=t in order to
use ticky-ticky, because it entailed a different closure layout. No longer.
You still need to do make way=t in rts/ in order to build the ticky RTS,
but you should now be able to mix ticky and non-ticky modules.

* Some of the counters that worked in the past aren't implemented yet.
I was originally just trying to get entry counts to work, so those should
be correct. The list of counters was never documented in the first place,
so I hope it's not too much of a disaster that some don't appear anymore.
Someday, someone (perhaps me) should document all the counters and what 
they do. For now, all of the counters are either accurate (or at least as
accurate as they always were), zero, or missing from the ticky profiling
report altogether.

This hasn't been particularly well-tested, but these changes shouldn't
affect anything except when compiling with -fticky-ticky (famous last
words...)

Implementation details:

I got rid of StgTicky.h, which in the past had the macros and declarations 
for all of the ticky counters. Now, those macros are defined in Cmm.h.
StgTicky.h was still there for inclusion in C code. Now, any remaining C
code simply cannot call the ticky macros -- or rather, they do call those
macros, but from the perspective of C code, they're defined as no-ops. 
(This shouldn't be too big a problem.)

I added a new file TickyCounter.h that has all the declarations for ticky
counters, as well as dummy macros for use in C code. Someday, these 
declarations should really be automatically generated, since they need
to be kept consistent with the macros defined in Cmm.h.

Other changes include getting rid of the header that was getting added to
closures before, and getting rid of various code having to do with eager
blackholing and permanent indirections (the changes under compiler/ 
and rts/Updates.*).

Supporting x86_64-apple-darwin in the NCG basically boils down to supporting
position-independent code in the NCG.
PIC code works almost exactly the same as on x86_64-linux, while position-dependent
code is not supported at all.
This patch implements -fPIC for x86_64-linux, too, but that is untested.

should fix profiling and unreg in HEAD

A GHC binary can generally build either registerised or unregisterised
code, unless it is unregisterised only.  

The previous changes broke this, but I think I've now restored it.

Push this further along, and fix build problems in the first patch.

  This allows you to put -fcontext-stack into an options pragma,
  as requested by Trac #829
  
  While I was at it, I added OptIntPrefix to the forms allowed
  in CmdLineParser.

Most of the other users of the fptools build system have migrated to
Cabal, and with the move to darcs we can now flatten the source tree
without losing history, so here goes.

The main change is that the ghc/ subdir is gone, and most of what it
contained is now at the top level.  The build system now makes no
pretense at being multi-project, it is just the GHC build system.

No doubt this will break many things, and there will be a period of
instability while we fix the dependencies.  A straightforward build
should work, but I haven't yet fixed binary/source distributions.
Changes to the Building Guide will follow, too.

Now, the threaded RTS also includes SMP support.  The -smp flag is a
synonym for -threaded.  The performance implications of this are small
to negligible, and it results in a code cleanup and reduces the number
of combinations we have to test.

We had to bite the bullet here and add an extra word to every thunk,
to enable running ordinary libraries on SMP.  Otherwise, we would have
needed to ship an extra set of libraries with GHC 6.6 in addition to
the two sets we already ship (normal + profiled), and all Cabal
packages would have to be compiled for SMP too.  We decided it best
just to take the hit now, making SMP easily accessible to everyone in
GHC 6.6.

Incedentally, although this increases allocation by around 12% on
average, the performance hit is around 5%, and much less if your inner
loop doesn't use any laziness.

unused imports

Profiling doesn't require -fvia-C any more.  Also, I optimistically
removed -fvia-C from all the other ways except unreg.

SMP: omit the -pthread flag on Windows

In many places there was a common pattern

when (verbose >= n) $ putMsg "..."

It is now replaced with

debutTraceMsg dflags n "..."

In few places hPutStrLn stderr or putStrLn was used instead of putMsg in
the above pattern. They are replaced too. Now putMsg is used only in places
where the verbosity flag was not checked.

Complete the transition of -split-objs into a dynamic flag (looks like I
half-finished it in the last commit).

Also: complete the transition of -tmpdir into a dynamic flag, which
involves some rearrangement of code from SysTools into DynFlags.

Someday, initSysTools should move wholesale into initDynFlags, because
most of the state that it initialises is now part of the DynFlags
structure, and the rest could be moved in easily.