Remove unused "Cleanup" shutdown function type

Reviewed By: jan, smith

Differential Revision: D1397106
Add a few try/catch blocks in SCOPE_EXITs in the runtime

Summary: Audited all of them to see if any could throw.  Mostly we're doing it
right.  They must always be nothrow because they are implemented as
destructors.

Reviewed By: @jano

Differential Revision: D1397107
Remove some old options (ThrowBadTypeExceptions, ThrowMissingArguments, etc)

Summary: This is apparently an old hphpc thing that deviated from php behavior
(presumably for performance?  Maybe it was part of HardTypeHints?).  Nothing
sets them to true anywhere, and it doesn't really control all the
warnings/exceptions one would expect anymore, so let's delete them.

Reviewed By: @alexmalyshev

Differential Revision: D1401231
Remove InjectedStackTrace runtime option

Summary: Legacy, and always set to true.

Reviewed By: @alexmalyshev

Differential Revision: D1401800
Remove ServerStackTrace runtime option

Summary: Unused.

Reviewed By: @bertmaher

Differential Revision: D1401845
Revert "Fixed casting Closure to Array"

Summary: It was causing a flib test to fail with infinite recursion, but this
wasn't being reported by sandcastle because of a bug in how we reported that
error (being fixed soon).

Reviewed By: @bertmaher

Differential Revision: D1410241
Reduce the number of exception types

Summary: It makes it too hard understand how we handle exceptions.  (Take a
look at handle_exception_helper in program-functions.cpp.)

Some notes:

  - Whenever we constructed a FatalErrorException from ExecutionContext's
    handleError, we apparently computed an extra PHP stack trace from the
    default ExtendedException constructor, and then threw it away.

  - m_handled was unused in Exception.  m_what is weird but I'm leaving it for
    now (it is a bit odd to add a newline character).

  - raise_error's ternary about whether to throw or not if the user error
    handler recovered had no effects, because the error handler wasn't even
    invoked there.  (We don't invoke the error handler on a fatal until after
    the entire eval stack is torn down.)

  - ExitException::ExitCode is a static member, shared across the request
    threads.  This means the exit callback might sometimes get incorrect exit
    codes in server mode if other request threads are concurrently doing Exit
    opcodes.  This looks like it was a hack for CLI mode: because it's hard to
    communicate anything useful to callers of hphp_invoke.  (I will try to make
    that fixable later.)

Stuff for later:

  - ParseTimeFatalException and AnalysisTimeFatalException probably have no
    reason to derive from Exception, but I'm not sorting that out yet.

  - FatalErrorException, ExtendedException, and Exception probably should all
    be combined into one class, but it requires sorting out 3 remaining
    subclasses (probably an enum is better than our rethrowing stuff).

  - We should stop throwing Object for user exceptions and have another,
    independent, std::exception subclass for that.

Reviewed By: @ptarjan

Differential Revision: D1404996
Remove defaulted args in hphp_invoke and hphp_invoke_simple

Summary: Necessary before possibly modifying hphp_invoke.  It's only slightly
less dangerous after this diff.

Reviewed By: @elgenie

Differential Revision: D1405000
Refactor running psp hooks so it's not part of hphp_context_exit

Summary: Rather than sending a bool into the function---I want to make it
easier to deal with PSP as a separate step so we can possibly change whether it
runs after a request ends with a fatal.  The final defaulted arg was also only
for the PSP code, and the shutdown arg was always passed true.  I am changing
the RPCRequestHandler not to call the post-psp debugger hook because I think it
was probably actually not intentionally doing so (since it doesn't run psp).

Also removed the ExecutionContext* argument: hphp_session_exit seems to be
willing to assume we're doing it to g_context, and I think we can afford the
extra load from TLS.

Reviewed By: @jano

Differential Revision: D1405002