feat: explicit parallel deploy opt-in for non-Aspire templates

## Problem

Currently, when no service declares `uses: [other_service]` in azure.yaml, all deploys run sequentially for backward compatibility. This means templates with fully independent services (no inter-service dependencies) cannot opt into parallel deployment without artificially declaring a `uses:` edge.

**Aspire projects** are now fixed (PR #7776) — the build-gate policy implicitly enables parallel mode. But non-Aspire templates with independent services have no way to opt in.

## Proposed Solution

Add an explicit opt-in field in azure.yaml:

```yaml
# Enables parallel deploy for all services (no sequential fallback)
execution:
parallel: true
```

Or at the service-graph level:

```yaml
services:
api:
...
web:
...
uses: [api] # explicit dep, web waits for api
worker:
...
# no uses: -> runs in parallel with api
```

## Key Considerations

1. **`uses: []` cannot work** — due to `omitempty`, an empty list is indistinguishable from an absent field at the YAML/Go level.
2. **Backward compatibility** — sequential must remain the default for existing templates that may rely on implicit ordering.
3. **Scope** — this affects deploy ordering. Provision parallelism is already controlled by `infra.layers` + `dependsOn`.
4. **Extension support** — the field should be generic enough for extensions to consume.

## Context

- Raised by @vhvb1989 during PR #7776 review
- Aspire parallel was fixed separately via the build-gate policy mechanism
- The sequential fallback exists because pre-exegraph azd always deployed services sequentially, and some templates may depend on that ordering via hook env vars

## Related

- PR #7776 (exegraph execution engine)
- `cli/azd/internal/cmd/service_graph.go` — `hasExplicitOrdering` logic