feat: Add traceability and log messages

[HofmeisterAn]

We've noticed that developers occasionally run into issues while using Testcontainers for .NET, especially when working with alternative container runtimes like Podman or Rancher Desktop. These problems seem to originate from the upstream dependency Docker.DotNet.

The issues typically involve failures in processing response messages. Something goes wrong in the communication layer. So far, Docker.DotNet hasn't offered an easy way to trace or debug these kinds of issues, making it super complex and time consuming to figure out what's actually going wrong.

This PR introduces the first step towards improving traceability and debuggability in Docker.DotNet:

• The CreateClient(Version, ILogger) method now accepts an ILogger instance. Developers can pass in their own logger to capture detailed logs from Docker.DotNet.
• The logger instance is wired internally using dependency injection. This should help us (and the community) better understand and diagnose problems in the future, improving the overall developer experience.
• The logger is used inside the BufferedReadStream implementation. It logs:
  • The raw response data being read from the buffer and stream.
  • Start and end positions of lines.
  • The actual extracted lines.
• I've cleaned up and updated the logic for handling chunked streams and improved how BufferedReadStream extracts lines separated by \r\n.
• Tests have been refactored to reuse more of the TestFixture. I also added support for xUnit.net's IMessageSink to capture log output during tests.

How to view logs in Rider

To view the logger output in JetBrains Rider:

1. Go to File | Settings | Build, Execution, Deployment | Unit Testing | Test Runner.
2. Set Logging level to VERBOSE.
3. Run your tests.
4. Open the Diagnostics tab in the Tests Tool Window to view the logs.

Not exactly sure where they show up in Visual Studio, if anyone knows, feel free to drop a comment.

Follow-ups

While I was working on this branch, I noticed that sending messages to stdin does not work properly, regardless of whether we are attached to the container or running a command inside it. Additionally, I found that the entire IExecOperations interface is not well-structured, and the models are outdated. We need to address these issues in a separate PR.