Predict Int for %, Double for /.

These operators produce unpredictable results. However, in the
vast majority of correct programs they produce a numeric type.
There's some uncertainty for /, so favor Double. We could
ultimately profile-drive this if we want more precision.
Fix bug, increase coverage for binary arithmetic.

Our attempts to handle reffy left-hand-sides for *= and friends
have always been broken. I noticed this while debugging an assertion
failure caused by misparenthesizing a check in analyzeSetOpL.
Separate "yield break" from "yield" parsing

"yield" and "yield break" are fundamentally different statements. Separate
their parsing paths and don't generate unused goto labels for "yield
break".

Parser's m_generators logic was updated to cope with zero labels case
that is now possible. A test case was added to cover this case.
Transform only foreaches with yield statements inside

Use the FunctionContext parser abstraction to keep track of
open foreach statements and presence of yields.
Move the inline vs. generic RetC cases into subroutines

Cut down a tad on function growth hormone imbalance syndrome.
Improve generic dtor stubs and support frame-less shared TC stubs

By allowing avoiding frames and using a custom calling
convention, combines the two generic dtor stubs and fits them on one
cache line.  Also inlines the call-table lookup for release helpers
instead of jumping to a C++ stub that does it.
Improve the generic freeLocalsHelper

Removes more branches from common cases in the
frameFreeLocals helper by calling to different offsets in a
generic-decref slide.  Also inlines the decref and destructor calls
instead of calling out to tvDecRefHelper.  To support this it also
always emits the varenv check (for AttrMayUseVV) and decrefs
ActRec::m_this in translateRetC translation.  For now this removes the
limit on total number of locals to do a specialized return (it leaves
the limit on number of reference counted locals).
Don't guard on nonrefcounted locals at RetC

If a local is known not to be reference counted at a given
RetC site, we don't need to guard on it when doing an inline return.
Use in-memory SQLite journaling for hphpc.

Use in-memory SQLite journaling for hphpc, since any hphpc failure by
definition results in an unusable repo anyway.
Nop out trivial CastDouble's.

I noticed this in je's command-line script and in histograms
of interp'ed instructions from www. A lot of the time (double) is just
to make sure on something that was already a double.
Sorting for collections

This diff adds support for Vectors to sort and usort, and adds support for
StableMaps to asort, ksort, uasort, and uksort.
enterTC code tweaks

A few minor tweaks.  Changes things so the compiler will
inline the fast path of getTranslation, only stores service request
args when there is a non-REQ_EXIT request, and removes the resume()
virtual since we're using TranslatorX64* in bytecode.cpp anyway.
Lock reads from the APC prime file

Thread building blocks issues -- concurrent map only uses spin locks
and calls sched_yield to pause, which just doesn't work well. If there
is any contention, it causes the system to spin like crazy.

This type of contention seems to be happening at startup when many
people are trying to use the same variables from APC. Based on profiling
I think that people are trying to read data structures that are very
array heavy, and in the handleUpdate spend a lot of time freeing it, all
while holding a writer lock.

This diff introduces a lock when you first read the piece of data from
disk. Because you hold a reader lock with the const_accessor, there's
no risk of the datastructure itself being freed. One thread is allowed
to read the object.

This also introduces a SmallLock datastructure which implements a mutex
in the space of a single int. As noted in the comments, this could be
made smaller. It could also be extended to other small locking structures
(eg, a pointer that could also serve as a lock).
Static type guards for Iter* bytecodes

We often know the type of an iterator
statically. Add meta data to avoid guarding
on the type in those cases.
Fix order in which classes get their traits imported

We were not enforcing that traits from base classes are imported
before importing traits in their derived classes.  This could result
in a derived class with an abstract trait method not "seeing" a
concrete definition of this method if the parent method got that
definition from a trait as well.  This would result in a "pure
virtual" fatal being thrown.
Mixed int/double math.