Allow configuring subnetworks in GCP settings

[jagretti]

Closes #4254

Adds an optional subnetworks field to the GCP backend config — a mapping from regions to subnet names in the VPC specified by vpc_name:

projects:
- name: main
  backends:
  - type: gcp
    project_id: my-project
    regions: [europe-west4]
    vpc_name: my-vpc
    subnetworks:
      europe-west4: my-subnet
    creds:
      type: default

Previously, dstack always provisioned in the first usable subnet returned by ListUsableSubnetworks for the VPC and region, with no way to influence the choice. This is limiting when a VPC has multiple subnets in the same region serving different purposes — especially for private gateways and fleets with public_ip: false, where clients can only reach the VMs if they land in a subnet the client network routes to.

Behavior

• In mapped regions, instances, gateways, and TPUs are provisioned in the specified subnet (matched by name against usable subnets of the VPC; shared VPCs supported).
• In unmapped regions, behavior is unchanged: any usable subnet of the VPC is used. With subnetworks unset, behavior is identical to before.
• Backend config validation errors early if subnetworks is set without vpc_name, if it's keyed by a region not in regions, or if a mapped subnet doesn't exist in its region (the error lists the available subnets).
• extra_vpcs/roce_vpcs subnet selection is unchanged (out of scope).

The field shape and behavior mirror the Azure subnet_ids setting (#3955).

Testing

• New unit tests for subnet matching (TestGetVpcSubnetOrError) and configurator validation; uv run pytest src/tests/_internal/core/backends/gcp/ passes.
• Docs updated in concepts/backends.md; the reference page picks up the field description from the model schema.

🤖 Generated with Claude Code