(This adds overlay support to Ptrace and Xen-Process; adds target API
support for reading symbols (not addresses) and placing probes on
symbols (not addresses).  It adds some really basic support for php's
dynamic symbols, but nothing complicated for things like objects and
hashes; how to handle those is unclear.  Finally, it's available in
dumptarget, backtrace, and spf.)

The PHP backend assumes it is stacked atop a process-level backend that
provides C-symbol-level access to process running the PHP 5.x
interpreter.  It reads key datastructures to assemble its understanding
of PHP-level "debugging symbols"; install function breakpoints; and read
symbol values.

PHP's compiler and execution engine (zend) is written in C.  The PHP
backend obtains its "debugging" symbol information by reading parsed
and compiled class types and the global function list (which includes
both internal, C-level functions aliased with PHP names; and user-written,
PHP native functions).  It does not support raw memory nor CPU register
access, since the PHP language does not provide those constructs.  Rather,
it allows users to install "breakpoints" on function entry.  It does this
by placing probes on the underlying target at the C level, on the actual
C function that executes a PHP function; when that probe is hit, the PHP
target checks its list of "breakpoints" for those associated with the
PHP function.  The user can then load the PHP function arguments using
the target API.  The back end also supports unwinding PHP function call
stacks.

The PHP back end does not yet support global or local variables; nor PHP's
more complex "basic" hashtable and object types.  We don't implement a
strategy for caching debugging symbols, or updating the info as new parts
of scripts are compiled and/or executed -- that is nontrivial and time-
consuming.  Supporting statement breakpoints would also be hard because
we cannot easily hook PHP in a single place to implement them.  PHP provides
PHP debugger extension writers with hooks in the executor to do just that;
but those hooks are not really available to us.  There are *many* opcode
handlers, and finding a point to place a C-level breakpoint to emulate
a PHP statement breakpoint is quite hard.  We'd probably have a lot of
such points!

It *does* support either threaded or non-threaded PHP interpreters; this
matters to use because each thread keeps its own copies of "global" data
structures (like compiler and executor state).  That doesn't mean it
supports multiple PHP threads :).  It supports single-threaded PHP
processes where the PHP binary was compiled with multi-thread support.

Lots more details in the comments...