refactor: Reuse the the builder configuration in local mode

[HofmeisterAn]

Hi @nkz-soft 👋 I finally had some time to look into and test the pull request related to the Compose feature. While reviewing and testing the PR, I made some changes that I would like to discuss with you first:

1. The DockerComposeBuilder.Build() member can determine which DockerComposeContainer implementation should be returned. I don't believe we need DockerCompose and the proxy implementation. Additionally, to 2. this reduces the amount of necessary configurations.
2. I propose to reuse the builder configuration in the local Docker Compose mode. The command line builder is probably unnecessary as well. The idea is to set the entrypoint configuration to the compose command, such as docker compose --file docker-compose.yml, and use the command configuration for the actual compose command options, e.g., up [OPTIONS]. This has the advantage that developers can easily append options using the WithCommand(string) API.
   • Using this approach makes exposing additional (compose) options, such as RemoveImages, unnecessary as well. We can implement WithRemoveImages(RemoveImages) simply by:

   public DockerComposeBuilder WithCleanUp(RemoveImages removeImages)
   {
       return WithCommand("--rmi", removeImages);
   }

WDYT? Out of simplicity, I removed some parts related to the tests. I would like to discuss a few things first before we finalize the tests again.

[HofmeisterAn]

How can we actually test if the configuration is running? How do we obtain the endpoint of a service, such as the actual hostname and port?

[nkz-soft]

To fully support tests with services or containers, we need to introduce an additional abstraction, like listChildContainers in Java. At the moment I would limit myself to checking availability using healthchecks in the file itself.

[nkz-soft]

Hi @HofmeisterAn.

Unfortunately, I've been very busy for the last month.
Let's agree on which Java implementation features we will support?

The DockerComposeCommandLineBuilder class was made just to be able to handle methods like WithOptions, RemoveImages and others. The main idea was that the options can be applied both at startup (which can be replaced by calling WithCommand) and when the container is stopped (e.g. -rmi). If we don't support these features in this version, there's no question. But I think we will have to come back to it later anyway.

Anyway, this seems like a first step and we can add the necessary functionality later if needed.