Comments and white space
Move Outputable instance for FloatBind to the data type definition
Tiny refactoring, plus comments; no change in behaviour
Add Output instance for OrdList
Make Core Lint check the let/app invariant

If we have an invariant, Lint should jolly well check it.

(And indeed, adding this test throws up Lint errors that
are fixed in separate patches.)
Don't float into unlifted function arguments

We were inadvertently destroying the let/app invariant,
by floating into an unlifted function argument.
When desugaring Use the smart mkCoreConApps and friends

This is actually the bug that triggered Trac #9390.  We had
an unboxed tuple (# writeArray# ..., () #), and that writeArray#
argument isn't ok-for-speculation, so disobeys the invariant.

The desugaring of unboxed tuples was to blame; the fix is easy.
Make buildToArrPReprs obey the let/app invariant

Vectorise.Generic.PAMethods.buildToArrPReprs was building an expression like
   pvoids# (lengthSels2# sels)
which does not satisfy the let/app invariant.  It should be more like
  case lengthSels2# sels of l -> pvoids# l

This was caught by Core Lint (once it was taught to check for the invariant)
Document the maintenance of the let/app invariant in the simplifier

It's not obvious why the simplifier generates code that correctly satisfies
the let/app invariant.   This patch does some minor refactoring, but the main
point is to document pre-conditions to key functions, namely that the rhs
passed in satisfies the let/app invariant.

There shouldn't be any change in behaviour.
Extensive Notes on can_fail and has_side_effects

In fixing Trac #9390 I discovered that I *still* didn't really understand
what the can_fail and has_side_effects properties of a PrimOp mean, precisely.

The big new things I learned are

* has_side_effects needs to be true only of *write* effects,
  Reads (which are, strictly speaking, effects) don't matter here.

* has_side_effects must be true of primops that can throw a synchronous
  Haskell exception (eg raiseIO#)

* can_fail is true only of primops that can cause an *unchecked* (not
  Haskell) system exception, like divide by zero, or accessing memory
  out of range through an array read or write.

I've documented all this now.  The changes in this patch are only
in comments.
Refactor the handling of case-elimination

Mainly in Simplify.rebuildCase.  The old code wasn't wrong, but I kept
mis-understanding it.  This patch cuts splits out "pure seq" from "strict
let", which makes it much easier to grok.
Add has_side_effets to the raise# primop

According to the definition of has_side_effets in PrimOp,
raise# clearly has side effects!  In practice it makes little
difference becuase the fact that it returns bottom is more
important... but still it's better to say it right.