Add transient factory support to container

[coisa]

Problem

The php-fast-forward/container package currently exposes only singleton-style service/factory behavior, which makes it impossible to define dependencies that must be rebuilt on every get() call. This blocks use cases that rely on ephemeral collaborators, non-shared adapters, and short-lived orchestration objects.

Proposal

Introduce explicit transient factory support in the container so certain factory definitions bypass the shared-instance cache and are executed on each resolution. Singleton behavior should remain the default and continue to be the compatibility-preserving mode.

Goals

• Add a dedicated, explicit API surface to register transient factories.
• Keep existing registrations singleton by default for backward compatibility.
• Preserve current container entrypoint semantics and exception behavior.
• Ensure container internals expose enough visibility to detect and test shared vs transient resolution paths.

Expected Behavior

• A dependency registered as transient is instantiated (or rebuilt) every time the container resolves it.
• Singleton registrations continue returning the same shared instance across calls.
• Existing usages that rely on current singleton defaults remain unchanged and passing.

Implementation Strategy

1. Review the container resolution pipeline to identify where instances are currently cached and reused.
2. Add metadata/flags to mark factory definitions as transient.
3. Add a public registration API (or extension of an existing one) for transient factories.
4. Update resolution logic to skip cache write/read for transient definitions while keeping singleton caching unchanged.
5. Add unit tests covering:
   • transient factory returns different instance per get()
   • singleton keeps the same instance
   • mixed usage across chained dependencies behaves deterministically
6. Update container docs/README to show transient registration examples.

Non-goals

• No dependency graph redesign for external container integrations.
• No automatic constructor auto-discovery changes.
• No changes to PHP type system contracts unrelated to lifetime behavior.

Functional Criteria

• A transient factory can be registered via container API.
• The same transient factory is executed at each resolution call.
• Singleton registrations remain cached and return identical instances across calls.
• Existing singleton and existing behavior tests remain green after implementation.
• Documentation reflects the difference between singleton and transient factory registration.

Architectural / Isolation Criteria

• MUST: The core logic MUST be isolated into dedicated classes or services instead of living inside command or controller entrypoints.
• MUST: Responsibilities MUST be separated across input resolution, domain logic, processing or transformation, and output rendering when the change is non-trivial.
• MUST: The command or controller layer MUST act only as an orchestrator.
• MUST: The implementation MUST avoid tight coupling between core behavior and CLI or framework-specific I/O.
• MUST: The design MUST allow future extraction or reuse with minimal changes.
• MUST: The solution MUST remain extensible without requiring major refactoring for adjacent use cases.