We currently allow ConstantExprs occur for any side-effect free LLVM IR
instruction, and use ConstantExpr::get as the primitive constant folding API in
LLVM.

This doesn't make sense for a number of reasons:

a) code generators can't codegen arbitrary constant exprs at arbitrary places,
causing global variable initializers to explode in funny ways if the optimizer
gets creative.  
b) constant expressions like divides canTrap() which is a common source of
bugs.
c) optimizers typically treat constants as cheap or free, but a ConstantExpr
can have arbitrary cost.
d) optimizers try to handle both instructions and constantexprs equally well in
many cases, leading to complexity in PatternMatch.h and to the existence of the
Operator classes, which are gross.
e) we have no way to represent target-specific relocations that don't
conveniently map to ConstantExprs.

Instead, I propose that we implement the following plan:

1. Switch everything off using ConstantExpr::get as constant folding API, onto
the InstSimplify APIs, which are more general and powerful anyway.
2. Move all of the constant folding logic out of ConstantExpr::get into
InstSimplify so that ConstantExpr::get *just* creates them.
3. Remove the canTrap() constant exprs, simplifying the world and cleaning up
tons of stuff.
4. Introduce new ConstantExprs for target specific things that we currently
need like darwin_symbol_difference.
5. Remove various extraneous constantexprs other than GEP and bitcast.
6. Introduce a new ConstantExpr "base_offset" node which takes a constant
pointer and integer and adds them together, returning a new pointer.  Teach the
optimizer to optimize them as well as ConstantExpr GEP's are right now.
7. Remove the gep constantexpr, leaving us with the target specific ones,
bitcast, and base_offset.
8. Profit!

-Chris