Block Hooks: Consider introducing a dedicated endpoint

[Bernhard Reiter]

It might be worth revisiting a dedicated endpoint for Block Hooks (as originally discussed in #59574 and attempted in ​https://github.com/WordPress/gutenberg/pull/58622). Such an endpoint would accept an anchor block (and optionally a context) as its arguments, and return the list of hooked blocks in each relative position for that anchor block. Specifically, its syntax would likely be something like this:

/wp/v2/hooked-blocks/core/post-content?entity=template&id=twentytwentythree/single
/wp/v2/hooked-blocks/core/page-list?entity=navigation&id=4

(Which would return a list of all blocks hooked to the Post Content if located inside of the TT3 Theme's Single Posts template, or to the Page List block if located inside the Navigation menu with ID number 4.)

So far, we've managed to avoid the need for an extra endpoint, and instead used the actual markup -- in particular the metadata.ignoredHookedBlocks attribute, plus the presence of hooked blocks in their expected position(s) -- to infer e.g. the state of the Block Hooks toggle. However, we're starting to push the limits of what's possible with that information. For example, in order to fix #60756, we'd need to change the format of ignoredHookedBlocks to include the relative position.

[Bernhard Reiter]

A dedicated endpoint would allow us to:

• Remove ignoredHookedBlocks injection on DB write (since we could instead inject the attribute into any newly added blocks in the editor) (introduced in #60506, further refined in #60671 and #60754).
• Avoid storing the relative position in ignoredHookedBlocks in order to fix toggle insertion (#60756).

[Bernhard Reiter]

In order to better integrate the endpoint with where it'd likely be used (i.e. chiefly in the Site Editor), @gziolo has suggested to ​embed it in e.g. the Templates endpoint.