Split Resolver into focused contracts (Resolver, Reflector, Augmenter)

[henriquemoody]

Summary

Reshapes the package around small, single-purpose contracts so consumers
depend on behaviour, not on the PSR-11 implementation. The Resolver becomes
an interface, the container-free reflection helpers move out into their own
class, and a new Augmenter contract covers the factory use case the resolver
was never meant to serve.

This is a breaking change; the branch aliases to 2.0.x-dev.

Changes

Introduce the Augmenter contract

• New Augmenter interface and ContainerAugmenter implementation.
• Unlike the resolver — which completes a call by padding gaps with defaults
  or null — the augmenter keeps the given arguments authoritative: never
  rebound, reordered, or padded. It only fills genuinely unfilled parameters
  with container services, added as named arguments.
• Variadic, builtin-typed, and already-filled parameters are never augmented;
  extra arguments pass through unchanged.
• Types listed as unresolvableTypes are never looked up in the container,
  which keeps value-like classes (clocks, dates) from being served as frozen
  services.
• Augmentable parameters are reflected once and cached per callable.

Extract Reflector from Resolver

• reflectCallable() and acceptsType() don't depend on the container and are
  useful on their own, so they move to a dedicated Reflector.

Turn Resolver into an interface

• Resolver is now the resolution contract; the concrete PSR-11 class is
  ContainerResolver, mirroring the Augmenter/ContainerAugmenter split.
• The static helpers already living in Reflector are dropped from the class.

Upgrading from 1.x

• Resolver is now an interface; instantiate ContainerResolver instead.
• Resolver::reflectCallable() and Resolver::acceptsType() moved to Reflector.
• The new Augmenter/ContainerAugmenter fill unfilled parameters without
  touching the given arguments.

Tests

• New ContainerAugmenterTest and ReflectorTest; ResolverTest renamed to
  ContainerResolverTest.
• Added fixtures (OptionalServiceConsumer, tests/fixtures/functions.php).

🤖 Generated with Claude Code

[alganet]

I'll wait for your response in #26. If we don't introduce another kind of resolving, I would prefer keeping it contained in a single class.

Even after merging augmenter+resolver as I proposed in the diff, Resolver.php stays very small at less than 300 lines. IMHO, introducing _other kinds of resolving* complicates things more than the benefit obtained by separating responsibilities.

I could be wrong though, and maybe you have a plan or a use case that my comment on #26 does not address, or perhaps a better reasoning for making the architecture larger. I'm all ears!