Compute FPI PrepKinds using method names in hhbbc

Summary: This is one thing hphpc still does that hhbbc doesn't.  But the code
that sets Expression::RefValue into the context bits is incorrect if you don't
run the inferTypes pass, so we can't use it if we want to stop doing that.
Redoing the optimization here is pretty easy.

Reviewed By: @edwinsmith

Differential Revision: D1443303
Add more reduce() cases for FPassR and FPassV

Summary: The cases here were less complete than I thought (I forgot I left some
out because reduce() doesn't support nesting, but it can't really use that
anyway).  Surprisingly this seems to get rid of all of the FPassV opcodes in
www (after D1444820 added some).

Reviewed By: @jano

Differential Revision: D1445476
Support nested uses of reduce() in hhbbc

Summary: The implementation of reduce and impl claim you aren't allowed to nest
opcodes that do reduce calls, but the code was doing it anyway.  In practice we
were never hitting the case, but we do after turning off FPassC/V changes in
emitter.cpp, so now we should support it, which isn't too hard.

Reviewed By: @edwinsmith

Differential Revision: D1447745
Compute AttrNoOverride functions in hhbbc instead of using hphpc's version

Summary: The bits coming in claim that private functions that are overridden
have AttrNoOverride.  So, let's throw the incoming bits away and recompute it
here.

Reviewed By: @jano

Differential Revision: D1444777
Disable FPassC and FPassV lowering in emitter.cpp

Summary: They apparently can make incorrect transformations, and if you turn
off inferTypes and postOptimize even more so (because Expression::RefValue is
apparently invalid without those passes).  Hhbbc now mostly does the same
FPI-passing optimizations (a little more conservatively, but hopefully also
more correctly), so if it's in the noise in perflab let's switch.

Reviewed By: @edwinsmith

Differential Revision: D1444820
Share more code in FCall* opcodes, fix a bug in FCallArray and FCallUnpack

Summary: Neither FCallArray nor FCallUnpack were properly handling functions
that never return (the latter copied the bug from the former).  This wasn't a
problem 'in practice' for FCallArray because currently it never has a resolved
func on the ActRec right now (because FPushCuf doesn't try to figure out which
func you're calling), but it was possible to cause hhbbc to crash with an
unpacking call to a function that can't return.  Fix this while setting up the
code to share a little more of the logic.

This diff also makes it so FCall (non-D) with a known resolved func will try to
look up the return type.  This can happen with the new kind of name-only
function resolution from D1443303, but currently they don't ever produce return
types better than TInitGen, so it's a no-op for now.

Reviewed By: @elgenie

Differential Revision: D1448343
Remove a few no-longer-needed emitter WholeProgram things

Reviewed By: @alexmalyshev

Differential Revision: D1451034
Improve hhbbc's behavior for builtin return types

Summary: If we don't know the type, we can still apparently check AttrReference
to avoid an UnboxR.  Also, apparently the returnType is set even for non-HNI
builtins.

Reviewed By: @jano

Differential Revision: D1454754
Split some of whole-program.cpp into subroutines

Summary: Separating some small amount of refactoring out of a diff that didn't
work.  (This function was too big.)

Reviewed By: @alexmalyshev

Differential Revision: D1459003