What is the problem you're trying to solve
Many users define in a compose file some additional container that they use during development as "one-off" tasks using docker-compose run command, but are not part of their compose application. As one can't disable a service in a compose file, they have to maintain a separated compose file, and then use explicit --file option.

It's also a common practice to have separated override compose file to address different environments, typically to configure some services with debug port exposed during development.

This proposal is about making those usage patterns more canonical by providing the adequate descriptive apporach to select a sub/superset of containers in a compose file, and apply some override files.

Describe the solution you'd like
Compose specification introduce a new concept as profile that a Compose implemenation can use to select the services to be ran when loading a Compose model.

1. Introduce a new profiles attribute at services level as a string list. If not set, it will default to profiles: ["default"]. In regards to Add option to specify services to be started by default #87 this is equivalent to auto_up: true

Compose implementations whith profile support MUST ignore services which have a profile attribute but don't match the current profile. Services without a profile attribute always match.

Selecting active profile(s) can be implemented by any mechanism, typically flags or environment variable DOCKER_COMPOSE_PROFILE, but this is an implementation detail not to be defined y the spec.

Running compose up with "debug" profile enabled will run:

• services with no profiles attribute
• services which profiles list includes "debug" in the profiles attribute.

2. Clarify by the specification the selection of an override compose file to be merged with the main one. With profile support, a Compose implementation will check for the presence of a compose-[profile].yaml file aside the main compose file, and automatically merge it with the main model. Adopting this pattern by the spec would actually make a common practice a canonical one - docker-compose already does this by loading a docker-compose-overrides.yaml file if present.

Additional context
This proposal is a follow-up for docker/compose#7539 (comment) and address #87