09: Loader resolution and registration

[nikolaystrikhar]

What: Loader resolves its interface-backed collaborators — from the container when one is bound, else a plain new — and buffers registrations until boot.

Usage:

use Nexcess\PluginAbsorber\Contracts\Registrar_Interface;

Config::set_hook_prefix( 'give' );

Loader::register( [
    'slug'                   => 'give-recurring',
    'bundled_plugin_file'    => __DIR__ . '/sub-plugins/give-recurring/give-recurring.php',
    'plugin_loaded_constant' => 'GIVE_RECURRING_VERSION',
] );

// Order does not matter — this still wins, and still receives the registration above.
$container->singleton( Registrar_Interface::class, My_Registrar::class );
Config::set_container( $container );

Loader::all(); // ['give-recurring' => Sub_Plugin]

Why this way: resolving inside register() pinned the default registrar at the host's first registration, so a container set afterwards was silently dropped — and the fix for that was a documented ordering rule nobody would read until it bit them. Buffering the built Sub_Plugin and draining it on the first read costs one array and makes set_container() order-independent like every other configuration call. The registrar keeps sole ownership of duplicate-slug detection and ordering rather than the buffer restating them, and the price of that is a duplicate slug being reported at boot instead of at the second register() call; an unusable config array is still rejected inside register(), where the host's stack trace points at it. There is no Loader::reset() — Registrar_Interface has no reset() to call, and a reset on the facade would be permanent public API bought for the test suite, so the statics are cleared by reflection from tests/_support/Loader_State.php.

Verify: slic run unit tests/unit/LoaderResolveTest.php (21 tests, 20 of them cases) and composer test:analysis. Both suite legs pass. Not covered here: boot(), the hook wiring and the load loop, which are #11; the container is only exercised through Registrar_Interface, since the other three collaborators do not exist yet.

[nikolaystrikhar]

@d4mation I don't think I like the static approach here as it will contain more logic.. In the end, I want to give it all to Justin to review the architecture as it's the first lib I'm working on and he has better ideas on consistensy and approaches.