Tabs -> spaces (and some other formatting)
Formatting wibbles
Rewrote vectorisation avoidance (based on the HS paper)

* Vectorisation avoidance is now the default
* Types and values from unvectorised modules are permitted in scalar code
* Simplified the VECTORISE pragmas (see http://hackage.haskell.org/trac/ghc/wiki/DataParallel/VectPragma for the spec)
* Vectorisation information is now included in the annotated Core AST
Vectoriser: fix vectorisation avoidance for case expressions
Vectoriser: distinguish vectorised from parallel types and functions

- We sometimes need to vectorise types and functions because they might be needed in a vectorised context, not because they do directly introduce parallelism.
Vectoriser: don't include scalar types in base set of parallel tycons
Vectoriser: enable encapsulation of scalar functional expression of arbitrary form
Vectoriser: improve top-level check and vectFnExpr
Vectoriser: VECTORISE pragma assumes parallel values
Vectoriser: don't pack free *scalar* variables
Vectoriser: depending set of a vectorised tycon need only be vectorised if also parallel
Minor impovement to when we float a let out of
a right-hand side:

Note [Float when cheap or expandable]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We want to float a let from a let if the residual RHS is
   a) cheap, such as (\x. blah)
   b) expandable, such as (f b) if f is CONLIKE
But there are
  - cheap things that are not expandable (eg \x. expensive)
  - expandable things that are not cheap (eg (f b) where b is CONLIKE)
so we must take the 'or' of the two.
Comments only (about trimming the type environment)
Update mailing lists in the users guide
Comments only
Exploit the invariant for AxInstCo to simplify coercionKind
When printing types in the interactive UI, take account of free variables

Often the types we print are full-generalised, but in fact *kinds* are
not, so we need to use tidyOpenType.

Fixes Trac #7587
Merge branch 'master' of darcs.haskell.org:/home/darcs/ghc
Use pprTypeForUser when printing kinds in ghci
Ensure the LLVM codegen correctly handles literals in a branch. #7571

We need to be sure that when generating code for literals, we properly narrow
the type of the literal to i1. See Note [Literals and branch conditions] in the
LlvmCodeGen.CodeGen module.

This occurs rarely as the optimizer will remove conditional branches with
literals, however we can get this situation occurring with hand written Cmm
code.

This fixes Trac #7571.

Signed-off-by: David Terei <davidterei@gmail.com>