Support Test Containers

[cwinland]

Description:
Enable support for test containers to facilitate integration testing. Goals:

• Container lifecycle management for test environments
• Integration with FastMoq setup and teardown flows
• Compatibility with Docker, Testcontainers.NET, or similar frameworks
• Sample usage in real-world scenarios

[cwinland]

A more precise scope for this issue would help keep it actionable and separate it from the broader diagnostics work in #41.

Suggested refinement:

• focus FastMoq container support on safe lifecycle patterns and actionable startup failures rather than full container orchestration ownership
• preserve the primary startup exception when Docker or the configured Testcontainers endpoint is unavailable
• make teardown safe when container creation or startup fails before a container handle is fully assigned
• provide one or two public sample patterns for xUnit fixture or async lifecycle usage
• emit minimal actionable diagnostics for container startup failures:
  • the runtime or endpoint that was attempted
  • the image or container role being started
  • where Testcontainers configuration can override the default endpoint
• keep examples generic and public, for example Azurite, Redis, or ClickHouse
• keep richer structured logging, traces, and graph-style diagnostics under Structured Logging & Diagnostics #41 rather than expanding this issue into a general observability feature

Concrete acceptance criteria:

• a failed container startup surfaces one clear root exception
• teardown does not throw a second exception if startup never completed
• sample fixture patterns show safe initialize and dispose behavior
• the guidance stays compatible with Testcontainers.NET instead of replacing it

[cwinland]

Closing this for now as not planned.

Reasoning:

• the current highest-value backlog is still provider-first API completion, migration analyzers, and the xUnit v3 move
• FastMoq does not currently have a Testcontainers runtime surface, and adding container lifecycle ownership would push the library outside its core mocking/test-infrastructure scope
• if we later need guidance for Azurite, Redis, ClickHouse, or similar fixtures, that is better tracked as sample or cookbook material unless a concrete reusable FastMoq API gap appears