Interactivity API: Make class WP_Interactivity_API minimally extensible

[nickchomey]

Trac ticket: https://core.trac.wordpress.org/ticket/65757#comment:19

As per the discussion in the trac ticet, this PR aims to make the Interactivity API's WP_Interactivity_API class - used for server side processing of directives - minimally extensible.

Removing final from the class is the most minimal change that needs to be made to achieve this goal, without changing the private and protected status of the various properties and methods. But the concern still remains that even if someone wrote their entirely own class rather than override the methods/properties, it would still lock the API into a public contract.

So, this PR implements a pattern that is used in Gutenberg, and in the interactivity package in particular: an explicit developer opt-in when they are using an unstable/internal/private API. This would be achieved by defining a WP_INTERACTIVITY_ALLOW_PRIVATE_API const and also using the wp_interactivity_instance filter to replace the class instance with one that extends it.

Feedback on the possibility of this approach would be quite welcomed.

Use of AI Tools

AI assistance: No

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.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props nickchomey.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.