Phase 2 resource support: dynamically loadable resource plugins

[knoepfel]

Scope

Phase 2 supports resource registration from dynamically loaded plugins through the same discovery and loading mechanism used for modules, sources, and drivers. A resource provider can construct and register framework-owned resources from workflow configuration without requiring the resource type or its construction details to be compiled into the application.

This phase builds on the registration and dependency machinery in Phase 1 (#851). It is independent of the multi-token work in Phase 3 (#853) and has no upstream oneTBB dependency.

Proposed Registration Shape

A resource plugin will use a registration macro with the following shape:

PHLEX_REGISTER_RESOURCES(r, config)
{
  r.add_resource<T>(/* construct from config */);
  r.add_resource<U>(/* construct from config */);
}

The registration opener receives the graph's resource-registration interface and resource configuration. It interprets the configuration and registers each resource with add_resource<T>(...).

Resource plugin libraries must be loaded before other plugins so that algorithms, sources, and drivers can declare dependencies on registered resources.

Required Work

1. Define the resource-plugin registration macro, callback parameter types, and ABI following the established conventions for dynamically loaded modules, sources, and drivers.
2. Specify the workflow configuration artifacts that identify which resource plugins a Phlex job loads and supply their configuration.
3. Load resource plugins before other dynamically loaded plugin categories.
4. Ensure plugin registration errors retain the diagnostics and ordering guarantees established by Phase 1.
5. Add integration coverage for configuration-driven resource construction, dependency declaration from another plugin, ordering, and error handling.

The exact macro name and configuration schema should be selected as part of this issue rather than treated as fixed by the example above.