Added step out to debugger hooks and implemented step_out xdebug command

Summary: This diff implements the xdebug commands step_out. It does so by calling the
implemented function `phpDebuggerStepOut`.

I took a different approach than hphpd, I've outlined the core difference
below, but I can go into more detail if necessary. To a user of
`phpDebuggerStepOut` the two approaches would be identical. And my approach
could be used by hphpd as well.

I took a different approach because the addition of the
`phpDebuggerFuncEntryHook` and `phpDebuggerFuncExitHook` allows my approach to
be more general, less complex, and significantly less code. The cost is an extra
check every function exit when a debugger is attached.

The core difference between my approach and hphds is that my approach does not
try to set a breakpoint on the return address of the current function.
This is easy in the simple standard case, but when dealing with nested VM states
in things like generators, things get a lot more complicated. Hphpd
iterates up the stack trying to guess the sucessor to the return opcode in order
to set a breakpoint. Each iteration cases on the type of opcode. If the opcode
allows fallthrough we set a breakpoint on the next opcode, if it is a control flow
opcode a breakpoint set on the destination.

Instead, in my implementation we can check on function exit if the step-out
command is active and if the stack depth has decreased. If so, we then force the
interpreter and and we break on the next valid opcode.

Each of these explanations is simplified, hphpd especially. You can see
hphpd's implementation in `runtime/debugger/cmd/cmd_flow_control` and
`runtime/debugger/cmd/cmd_out`.

This diff also includes the following misc changes:
* Added separator for each section in the debug hooks. The sections already
  existed but I noticed when adding my changes the file was getting hard to
  follow.
* Added `phpDebuggerContinue`, which should be called by debuggers to continue
  execution. It just short-ciruits other commands if they are running.
* Unified the logic deciding if we should force debugger interrupts into
  a method of `RequestInjectionData` instead of duplicating it in
  `debugger-hooks`.

Reviewed By: @ptarjan

Differential Revision: D1502519
Added next command to debugger hooks and implemented step_over xdebug command

Summary: This implements the debugger hook command `phpDebuggerNext` and the xdebug
command `step_over`. These commands are used to step the current line of code,
stepping over function calls if necessary.

Hphpd "next" is, at a high level, a step in and then a step out if our stack
depth has increased. There is a lot of special casing, however, most of which
deals with resumable functions.

When stepping in, hphpd breaks on the next line, or in resumable functions, on
any exit opcode (return, yield, await). This is not used in the "step in" command
in hphpd and results in weird behavior as we are already on the line with
the exit opcode. However, This is used in the next command to determine which
opcode to step to next.

After breaking from a step in, the next command looks at the current opcode and,
if it is an await opcode, it sets a breakpoint on the opcode that will be
executed after the await. On yields it does either a step out or a step to the
next line, whichever happens first. On returns, it does a step out. In all of
these cases, in my implementation at least, simply letting the
step in continue would have achieved the same result: we would break on the next
opcode not on this line, which would be either be at a lower stack depth or at
or the resumed opcode for await/yield.

So my implementation does a step in and then a step out if our stack level has
increased. We maintain the "flow filter" from "step in" into "step out". This
allows us to ensure we break on the next line.

There is no casing over types of opcodes. This results in much simpler code and
empirically it results in in behavior identical to hphpd. I've tried to test this
thoroughly but it's possible I may have missed an edge case. Regardless, edge
cases could be much more easily integrated into this than if I had just pulled
hphpd's code.

Though it'd require an understanding of the hphpd next command in order to
refactor, this could be used by hphpd.

Reviewed By: @ptarjan

Differential Revision: D1502723