The `ZendAstPrettyPrinter` had logic to handle the various structures that are
based on `zend_ast`, like `zend_ast_decl`, but the printer was only installed
when the value was a `zend_ast`, meaning that for the specialized structures
the details wouldn't be shown unless they were cast (in GDB) to `zend_ast`.
Instead, just register the printer for the specialized structures too.
* Support IS_INDIRECT, IS_PTR, IS_ALIAS_PTR when printing zvals
* Pretty print the ce_flags field when pretty printing a zend_class_entry
* Pretty print the const flags when pretty printing a zend_class_constant
* Added a minimal zend_property_info pretty printer to pretty print the flags field
* Added minimal zend_function, zend_op_array, and zend_internal_function pretty printers: The string value is the function/method name, function type (user/internal), and location (when possible). The fn_flags field is pretty printed
* Added a minimal zend_op pretty printer to pretty print the opcode
* Added a zend_refcounted_h pretty printer to pretty print the type_info
* Added minimal pretty printers for zend_object and zend_array
* Print the type and address of pretty-printed structs
* Added gdb commands: print_fn_flags, print_ce_flags, print_prop_flags, print_const_flags, print_ref_type_info, print_opcode, dump_op_array
* Fields of type zend_string, zend_class_entry, zend_array are printed by default in all our pretty printers, using short representation
* Increased the maximum length of printed strings to 200 chars before truncation (was 50)
Given that the `ZEND_AST_OP_ARRAY` type already needed special handling in
various places, it makes sense to give it its own struct to avoid some of the
casts. As a side benefit, it is a little smaller than the `zend_ast_zval`
struct.
For `zend_string` pointers in class entries, show the string contents (if not
`NULL`).
For class constants, the `ce` (class entry pointer) field is shown with the
name of the class, and the `doc_comment` field is shown with the string
contents if possible.
This inlines .gdbinit and php_gdb.py in the .debug_gdb_scripts section of the PHP binary so that GDB can auto-load them regardless of the current directory or the availability of the PHP source code (albeit some functionalities of php_gdb.py currently rely on the source being available).
