run usercode before ending the request

A previous commit, 15bf01c8f58833733a7337ab975f6aa81105e211, changed
onSendEnd to ignore further output after onSendEnd was called. This
fixed a failure because a function registered through
register_postsend_function was sending output when the socket was
presumably already closed.

However, onSendEnd is called before hphp_context_exit. The latter
(among other things) executes destructors of live-at-end-of-request
objects. These destructors may execute user code, and are allowed to
send output. This behavior wasn't obvious, because it's hidden behind a
runtime option that is disabled by default (Eval.EnableObjDestructCall).

I initially tried to refactor the way hphp_context_exit works so that
we could first run shutdown handlers, then end our request, and
eventually execute the postsend functions. This requires significant
changes in several places (replacing hphp_context_exit calls, shuffling
the order of execution of things, moving session shutdown location). It
also had the (probably unwanted) side-effect of object destructors
having been called before postsend functions were executed.

We have a circular reference issue, and one of the two mechanisms has to
compromise. In favor of Zend compatibility I propose the following:
- Move things around so they execute in this order:
  onShutdownPostSend > hphp_context_exit > onSendEnd
- Revert the earlier commit, because there's no usercode after onSendEnd
  anymore.

This will prevent FastCGI failures but still allow object destructors to
send output.

There's one caveat:
postsend functions are now able to send output, though technically
post *send* doesn't necessarily mean post *send end*. It's hard to
prevent usercode from sending output, and since this is a facebook/HHVM
specific function I welcome all input on this.