Block Hooks: Allow traversal callbacks to modify parent block

[ockham]

tl;dr: In 6.5, we'll need arguments to two functions introduced during the 6.4 cycle to become references. Since that can be deemed a back-compat breaking change, I'm suggesting to make that change already.

---

The callbacks returned by make_before_block_visitor and make_after_block_visitor, respectively (which are passed as arguments to traverse_and_serialize_block(s)) currently accept three arguments, all of which are block arrays (i.e. with properties blockName, attrs, etc.):

• A reference to the block they're currently visiting, &$block;
• the block's $parent_block; and
• the $previous block (for make_before_block_visitor), or the $next block (for make_after_block_visitor), respectively.

Those arguments are passed to the "block visitor" callbacks by traverse_and_serialize_block(s) during traversal. The block that the callback is currently visiting is passed by reference to allow modifying it, which is e.g. used to inject the theme attribute into Template Part blocks.

One major limitation with Block Hooks is that they currently only work with templates, parts, and patterns that don't have any user modifications (i.e. that come straight from the corresponding theme files, rather than the DB). For WP 6.5, we're planning to change that to also make Block Hooks work for templates, parts, and patterns that do have user modifications: #59646.

The way we'll make this work is by storing an attribute on the "anchor" block. This is currently being developed in #5523.

While working on that PR, I noticed that that means that we'll also need to allow the aforementioned callbacks to modify not only the currently visited $block, but also the $parent_block -- i.e. to pass the latter argument by reference, too. This is consistent with the requirement of adding an attribute to an anchor block, as it's not only the currently visited block that can serve as an anchor block (in the case of before or after sibling insertion), but also its parent (for first_child and last_child insertion).

Per discussion with @hellofromtonya, changing the $parent_block argument to become a reference can be considered a backwards-compatibility breaking change. I'm thus suggesting to make that change already as part of 6.4, which is the cycle where the relevant functions were first introduced. This should have no impact on existing code, since nothing currently relies on $parent_block remaining unmodified by the respective callback, nor is anything currently modifying that argument.

Trac ticket: https://core.trac.wordpress.org/ticket/59776

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[hellofromtonya]

As explained, these changes are needed as continued iteration for 6.5 revealed pass by reference is required. Doing these changes avoids a BC break in the 6.5 cycle.

The change also includes a little bit of girl scouting to improve the @param documentation.

[ockham]

Committed to Core trunk in [57038], and backported to the 6.4 branch in [57039].