Reorganise the work list, so that flattening goals are treated in the right order

Trac #9872 showed the importance of processing goals in depth-first, so that
we do not build up a huge pool of suspended function calls, waiting for their
children to fire.  There is a detailed explanation in
     Note [The flattening work list]
in TcFlatten

The effect for Trac #9872 (slow1.hs) is dramatic.  We go from too long
to wait down to 28Gbyte allocation.  GHC 7.8.3 did 116Gbyte allocation!
Get rid of TcMType.newWantedEvVar(s)

Hardly used, not helpful.  Use newEvVar instead.
Fix type-variable details naming (fixes misleading debug output)
When flattening, try reducing type-family applications eagerly

This short-cut can improve performance quite a bit, by short-circuiting
the process of creating a fresh constraint and binding for each reduction.

See Note [Reduce type family applications eagerly] in TcFlatten

To do this I had to generalise the inert_flat_cache a bit, so that the
rhs is not necessarily a type variable; but nothing fundamental.
Implement a fast path for new constraints looking like (a~b), namely unifyWanted

Looking at some typechecker traces I could see places where we were laboriously
creating a Refl coercion.  This patch short-circuits the process.

See TcCanonical:
  Note [unifyWanted and unifyDerived]
  Note [Decomposing TyConApps]

I ended up with some refactoring, notably

  * I moved xCtEvidence, rewriteEvidence, rewriteEqEvidence
    from TcSMonad to TcCanonical

There are some knock-on effects, but only minor ones.
Testsuite wibbles from constraint-solver improvements
Tests for Trac #9872
Comments only: move flattening notes to TcFlatten