Avoid port conflicts on ports exposed by managed stacks

This is a meta issue for discussion on how to avoid conflicts on ports exposed by managed stacks with the compose provider.

Port conflicts can happen now in different situations given that the ports are exposed at the host network, for example:
* If the host is already using any of the ports (as in https://github.com/elastic/elastic-package/issues/2889).
* If multiple stacks are started from different profiles.

There are some improvements that could be done to avoid these situations:
* Avoid exposing fixed ports on the host network by default. Docker can expose ports on random ports, `elastic-package` could easily get them and use them in their subcommands. Ports that are not needed by elastic-package, such as package-registry, could be not exposed by default.
* Allow to customize ports per profile, this is not so straightforward because hosts and ports are hard-coded in several places.
* Combine both, by using random ports (or not exposing ports) by default, and adding a command to expose ports on demand, running some kind of proxy.

The issue names no files or tests. Start by tracing the compose provider and the subcommands that consume ports, then compare the listed conflict scenarios and proposed approaches. Done requires an agreed, testable scope for handling host-port conflicts across managed stacks.

Written by the indexing model from the issue text.