feat: support long syntax for image names and build tags

[ssam18]

Users can now write image as a map with name, tag, and digest fields instead of a plain string. The same long syntax works for entries in build.tags, so a single YAML anchor can drive both the service image and the build tags without string interpolation tricks.

The core parsing changes live in compose-spec/compose-go (see ssam18/compose-go feat/image-long-syntax); this PR wires in that dependency and adds loader-level tests. Once the upstream compose-go PR is merged and released, the replace directive here will be swapped for a normal version bump.

Example usage:

x-version: &version 1.0.0

services:
  my:
    image:
      name: myimage
      tag: *version
    build:
      context: .
      args:
        VERSION: *version
      tags:
        - name: myimage
          tag: *version
        - name: myimage
          tag: latest

[glours]

Thanks for the contribution. Before we can consider this, we'd need to understand what problem this solves that isn't already covered today.

Variable interpolation already handles the use case shown in the PR description:

services:                                                 
   my:                                                                                                                                                                                                                                                                                                        
     image: myimage:${VERSION:-1.0.0}                      
     build:
       context: .
       args:
         VERSION: ${VERSION:-1.0.0}
       tags:
         - myimage:${VERSION:-1.0.0}                                                                                                                                                                                                                                                                          
         - myimage:latest

This is simpler, already works today, and comes with additional benefits that the long syntax doesn't offer:

• Default values via ${VAR:-default}
• Runtime overrides via VERSION=2.0.0 docker compose build or a .env file
• Consistency with how every other string field in Compose handles parameterization

Could you help us understand:

• What specific limitation of variable interpolation does this address?
• Is there a user issue or request motivating this? We couldn't find one linked.
• How would we justify the added complexity to users who now have two ways to express the same thing, with one being strictly less capable?

Adding a new syntax for image and build.tags has a cost, it touches the Compose Specification schema, the compose-go parsing library, and the compose CLI. Every tool and library that consumes Compose files would need to handle the new oneOf. So we'd need a clear justification for why existing mechanisms aren't sufficient.

[ssam18]

@glours - your point is valid! Variable interpolation already handles this better than what I proposed here. Not worth the added complexity to the spec and tooling. Closing this one out.