Usage of additional_contexts with the service: directive should imply build time dependencies #12783

Description

The new service: directive for additional_contexts almost fulfills the dream of letting docker/docker-compose become highly usable in a monorepo scenario, where images depend on other images built on demand in the same repository. See https://stackoverflow.com/a/79487072/95653 for an 8-year-old question in that direction finally getting an answer.

However, the build time dependency created by the additional context is not represented anywhere, and as a result, most commands break. Please review the example below, which is adapted from the aforementioned Stack Overflow answer.

  a:
     image: service_a
     build: 
       dockerfile_inline: "FROM alpine"
  b:
     image: service_b
     build:
       args:
         BASE_IMAGE: service_a
       dockerfile_inline: "FROM service_a"
       additional_contexts:
         # instructs resolving `FROM service_a` to "service a" image
         service_a: "service:a"

If you run docker compose build, everything works as expected. However, if I do docker compose build b, I get failed to find target a. The problem can be easily understood by running docker compose config b, which will show that service a does not exist in the configuration when you specify b explicitly.

There is an ugly workaround, which is using a depends_on for creating a runtime dependency, which will force a into the config when b is specified explicitly. This will let me do docker compose run --build b, but it will startup both service b and a, and I although I think it is reasonable to want b, I usually do not want a. One can start to play with more workarounds, like adding a parallel tree of build dependencies with a no-op entrypoint, but everything starts to get cumbersome and you start to hit other bugs.

Everything would work out of the box if docker compose config b brought a into the config, but somehow managed to mark it as not to start.

Going further down, once this is fixed, the build time dependency graph should also be exposed to docker compose watch, but I guess that goes as a different bug later.