Also, look for libXXX.dll in addition to XXX.dll (see #1883, this
isn't really a proper fix, but it'll help in some cases).
And I tidied up the error message for a DLL load failure, though it's
still a bit of a mess because addDLL is supposed to return a (static)
string with the error message, but this isn't possible on Windows.

- This adds the new equational solver based on the notion of normalised
  equalities.  
- The new algorithm is conceptually much simpler and will eventually enable us
  to implement a fully integrated solver that solves equality and dictionary 
  constraints together.
- More details are at 
  <http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsSolving>
- The code is there, but it is not being used yet.

"LATEX_DOCS = YES" enables them

It used to point to a file on haskell.org, which didn't necessarily
describe the right version of core.

Now that we build haddock in the GHC build, we don't need to look for it
on the path.

This patch deals with a rather complicated situation involving
overlapping instances.  It's all explained in the commments
   Note [Subtle interaction of recursion and overlap]

The absence of this case make DoCon and regex-base fail with
an error about overlapping instances.  Now they work properly 
again.

Several things

 * Only gather call details for local things, not imported ones

 * When making auxiliary dictionary bindings in specDefn, remember
   to give them an unfolding.  Otherwise we don't gather call details
   for functions applied to them.

When binding x = e, we now attach an unfolding to 'x' even if
it won't be used because SimplGently is on. 

Reason: the specialiser runs right after SimplGently, and it (now)
only gathers call information for calls whose dictionary arguments are
"interesting" -- i.e. have an unfolding of some kind.

Mainly this means adding a binding for all the exports, e.g. as well as
    gtAddr# :: Addr# -> Addr# -> Bool
we also generate
    gtAddr# = let x = x in x

This means S_ISSOCK gets defined on Linux

An incorrect libraries/ prefix was being added.

The insertion code in UniqFM fails if a unique key
produces a negative FastInt. I've added an assertion to check
that each insertion uses a positive Unique.

Where do the negative uniques come from? Both Simom M and
I have run into this problem when computing hashes for data structures.
In both cases, we have avoided the problem by ensuring that
the hashes remain positive.

Required libraries now have 3 fields in the packages file, not 2

This patch makes an important change to the way that dictionary
functions are handled.  Before, they were unconditionally marked
INLIINE, but all the code written by the user in the instance
was inside that unconditionally-inlined function.  Result: massive
code bloat in programs that use complicated instances.

This patch make instances behave rather as if all the methods
were written in separate definitions.  That dramatically reduces
bloat.  The new plan is described in TcInstDcls
	Note [How instance declarations are translated]

Everything validates.  The major code-bloat bug is squashed: in particular
DoCon is fine now (Trac #2328) and I believe that #955 is also better.

Nofib results:

Binary sizes
        -1 s.d.      +2.5%
        +1 s.d.      +3.1%
        Average      +2.8%

Allocations
        -1 s.d.      -6.4%
        +1 s.d.      +2.5%
        Average      -2.0%

Note that 2% improvement.  Some programs improve by 20% (rewrite)!
Two get slightly worse: pic (2.1%), and gameteb (3.2%), but all others
improve or stay the same.

I am not absolutely 100% certain that all the corners are correct; for
example, when default methods are marked INLINE, are they inlined?  But
overall it's better.

It's nice that the patch also removes a lot of code.  I deleted some
out of date comments, but there's something like 100 fewer lines of
code in the new version!  (In the line counts below, there are a lot
of new comments.)

This patch significantly improves the way in which recursive groups
are specialised.  This turns out ot be very important when specilising
the bindings that (now) emerge from instance declarations.

Consider
    let rec { f x = ...g x'...
            ; g y = ...f y'.... }
    in f 'a'
Here we specialise 'f' at Char; but that is very likely to lead to 
a specialisation of 'g' at Char.  We must do the latter, else the
whole point of specialisation is lost.  This was not happening before.

The whole thing is desribed in 
    Note [Specialising a recursive group]


Simon