Make sort builtins faster

HipHop's current implementation for sorting PHP arrays is a bit unweildy,
with a lot of plumbing and layers of indirection that make it slow. Also,
the sorting algorithm used (zend_qsort) is relatively slow.

This diff delivers a more streamlined implementation for sorting PHP
arrays. Sort APIs were added to HphpArray and ZendArray, which allowed for
data-structure specific semantics for sorting a PHP array in place.
ZendArray works by creating an auxillary buffer of Bucket*'s, sorting the
buffer, and then rewiring the array's linked list. HphpArray works by
directly sorting the element store in place.

Both ZendArray and HphpArray do an initial pass over the array to do some
preparatory work before the sort algorithm runs. For sorts that use builtin
comparators (sort, asort, ksort, natsort, natcasesort), the types of values
are also observed during this first pass. Running the home page with some
simple instrumentation, I found that ~94% of these sorts invovle all
strings, and ~5% of these sorts involve all integers. By observing the
types during this first pass, we can use a specialized comparator for these
common cases and avoid performing type checks during the actual sort.

For now I've only updated sort, asort, ksort, usort, uasort, uksort,
natsort, and natcasesort. It might be nice to go after array_multisort and
collator sorts at some point in the future, though I'm not sure how much
that will matter for overall performance.
Improve function prolog guards

The prolog guards were optimized for the case of an
8 byte Func*. Now that we expect them to be 4 bytes,
optimize for that case, reducing the guard size from 23
to 14 bytes, and from 4 instructions to 2.

In addition, store the unguarded address in the Func's
prolog table; in the truly polymorphic case, when the
guard complains, we dont need to check again after
looking up the correct function in the prolog table.
Inline generator stack frames into Continuation body

- The generator body's ActRec, locals, and iters live in the Continuation
  object. The eval stack itself is still on the main stack. Moving the actual
  eval stack turned out to be really hard. It's also not necessary until we
  decide to support yield-as-expression.

- The Switch at the top, and the parse-time transform of yield-inside-foreach,
  are still there. Those can be gotten rid of separately.

- The FPushContFunc-This-FPassC-FCall sequence is gone, replaced by ContEnter.
  RetC is no longer emitted in generator bodies, replaced by ContExit. The new
  instructions are very simple; all they do is frame linkage and a jump into, or
  out of, the generator body.

- PackCont and UnpackCont are still around, but they're also greatly simplified.

- Unwinding, stack printing, and translator fixups needed a bunch of tweaking,
  and a bunch of asserts needed to be weakened or removed. These are the
  messiest parts of the diff.

- The one really gross part of this is the magic number just after the
  Continuation's AR. I use this when tracing the stack. The trouble is that an
  FP pointing outside the stack may now be pointing at a Continuation's AR, or
  into the C++ stack. This is the most "reliable" way I could find to
  distinguish the two cases. Is there a better way? I figured there must be some
  sort of API to tell where the C++ stack is mapped in, but I didn't find one.

- The changes are mostly unimplemented in the IR. The tests pass, because
  everything punts.

- Continuation is now a final class. The {Function,Method}Continuation
  subclasses are gone.