Wrap polyfills in namespaces

[adamziel]

This PR is an alternative to #133 that doesn't require calling polyfill_wordpress_apis().

php-toolkit relies on WordPress APIs, such as apply_filters(). Sometimes they're missing, e.g. in PHPUnit runtime, and they're implicitly polyfilled when including vendor/autoload.php:

if ( ! class_exists( 'WP_Exception' ) ) {
	class WP_Exception extends Exception {
	}
}

This polyfilling technique assumes the library is either:

• Loaded inside a WordPress plugin, where WP_Exception is already available
• Loaded outside of WordPress, where there's no WP_Exception class

However, it does not account an important third scenario that WooCommerce ran into:

• Loaded in a WordPress runtime, but before wp-load.php is included

Solution

This PR adds a WordPress\\ namespace to all the polyfills. The php-toolkit code then refers to the namespaced code.

Rationale

At the time of require "vendor/autoload.php", we don't know what the developer is going to do next. Maybe they'll include wp-load.php, in which case we must not load the polyfills. Or maybe then won't include wp-load.php, in which case we must load the polyfills. Exposing an explicit polyfill_wordpress_apis() function lets them decide.

The one downside is: php-toolkit will use the polyfills instead of WordPress core code paths even when running as a WordPress plugin. We could counteract that with:

<?php

namespace WordPress\\HTML;

if(class_exists('WP_HTML_Processor')) {
    class WP_HTML_Processor extends \WP_HTML_Processor {}
} else {
    class WP_HTML_Processor { /* ...full polyfill */ }
}

Testing plan

Confirm the CI tests pass – many php-toolkit PHPUnit tests rely on WordPress polyfills and won't work if polyfill_wordpress_apis() is not called or is incomplete.