Create a plugin template registration API

[aljullu]

This ticket is the counterpart of ​https://github.com/WordPress/gutenberg/issues/41401 in WP core, so we can create the backport PR.

The goal is to create an API that allows plugins to easily register block templates so they can be used in the Site Editor and can be hooked into the frontend rendering logic.

This PR includes the changes that need to be backported from ​https://github.com/WordPress/gutenberg/pull/61577 into WC core.

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

@youknowriad I've tested the PHP APIs in this PR and they are working as expected. Unfortunately, I didn't find a way to reproduce all the testing steps from ​https://github.com/WordPress/gutenberg/pull/61577. This PR doesn't include the JS changes from the original PR so template revert/removal doesn't work. Is it expected that this kind of PRs can't be tested right away, or am I missing something?

@Aljullu yes, that's fine, it means this PR can only be merged after the package update on Core.

Thanks for the review @peterwilsoncc! I have applied all your feedback.

Although this needs a little work before landing in the final release, I am a little tempted to merge the code in it's current form while performance is figured out so we can merge in the inital package update. What do you think @azaozz @noisysocks?

If there's no outstanding blocking comments I'm ok with this.

Although this needs a little work before landing in the final release, I am a little tempted to merge the code in it's current form while performance is figured out so we can merge in the inital package update. What do you think @azaozz @noisysocks?

If there's no outstanding blocking comments I'm ok with this.

@noisysocks Speaking of blocking comments, the code currently has some compatibility issues with PHP 8.2, as it introduces a dynamic property (WP_Block_Template::$plugin).
I also have concerns regarding ​https://github.com/WordPress/wordpress-develop/pull/7125#discussion_r1742133430 (might not work as expected).
In my opinion, this PR may not be ready to be merged in its current state.

Thanks for the review @anton-vlasenko! I have addressed all your feedback, I would appreciate it if you can take another look.

There is also ​this open discussion about finding a more performant way to retrieve the plugin author text, but I might need some assistance on how to proceed. Also I don't know if it's a blocker.

Although this needs a little work before landing in the final release, I am a little tempted to merge the code in it's current form while performance is figured out

Sounds good to me too after all of @anton-vlasenko's suggestions and fixes were added. Would be nice to address/fix the performance improvements from above but as that affect only the site editor don't think it is a blocker.

I've merged trunk in and renamed a class in the tests folder (ie, it won't effect your source code). If @anton-vlasenko is happy with the change a few hours ago then I think it's good to go.

I've merged trunk in and renamed a class in the tests folder (ie, it won't effect your source code). If @anton-vlasenko is happy with the change a few hours ago then I think it's good to go.

@peterwilsoncc I don't see any blockers at the moment. Thanks!

I've merged in trunk and pushed a couple of test nitpicks in e8b2b2c1fa4047d0df2e1d4be624d3814fb971ff and some docs standards fixes in 9a18a250fe89552522188e2d9e2a254cf7e9dd1a

I think this is good to go in, @noisysocks are you able to take a look to make sure I am not missing something obvious that will effect the editor?