Expose supported Docker Compose deployment extensibility points to avoid reflection

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

I am building a third-party deployment integration on top of `Aspire.Hosting.Docker` and want to reuse the Docker Compose publisher pipeline instead of reimplementing it.

Today, the public API is enough for customizing generated compose output, but not for reusing or extending the actual Docker Compose publish/prepare pipeline from another deployment target. To make this work, I currently have to use reflection against internal or non-public members such as:

- `DockerComposeEnvironmentResource.PublishAsync(...)`
- `DockerComposeEnvironmentResource.PrepareAsync(...)`
- `DockerComposeEnvironmentResource.ConfigureComposeFile`
- `DockerComposeEnvironmentResource.Dashboard`
- `DockerComposeInfrastructure`
- `DockerComposeAspireDashboardResourceBuilderExtensions.CreateDashboard(...)`

This is brittle across versions and makes third-party deployment targets depend on internal implementation details.

### Describe the solution you'd like

Please expose supported extensibility points for Docker Compose-based deployment integrations so that third-party publishers/deployment targets can reuse Aspire's compose generation pipeline without reflection.

For example, one or more of the following would solve the problem:

1. A public or protected way to invoke the Docker Compose publish/prepare stages.
2. A supported API for creating/attaching the Docker Compose Aspire dashboard resource.
3. A supported way to register the Docker Compose infrastructure/services needed by the environment.
4. A documented extension model for custom deployment targets that want to build on top of `Aspire.Hosting.Docker`.

The key goal is to let external integrations reuse the existing compose publisher behavior exactly as Aspire does, while swapping only the final delivery/deploy step.

### Additional context

The currently available public APIs such as `AddDockerComposeEnvironment(...)`, `ConfigureComposeFile(...)`, `ConfigureEnvFile(...)`, `WithDashboard(...)`, and `PublishAsDockerComposeService(...)` are useful, but they do not seem sufficient for this scenario.

Related but not identical issues:

- #11209
- #9744
- #13793