Azure Container Apps: express deployment ordering for container apps sharing a managed environment

### Summary

Azure Container Apps serializes write operations within a managed environment. Creating or updating two container apps in the same environment concurrently fails with:

```text
Code: ContainerAppOperationInProgress
Message: Cannot modify a container app '' because there is an active provisioning operation in progress. OperationId: '...'.
```

The `aspire deploy` path avoids this because it applies deployment targets one at a time. However, the application model does not express any ordering relationship between container apps that share an environment. Consumers that build their own deployment orchestration from the model graph (rather than deploying sequentially themselves) have no edge to tell them these apps must not deploy concurrently, so they deploy them in parallel and hit the error above.

### Request

Have `AddAzureContainerAppEnvironment(...)` (or the container-app deployment-target processing) express deployment ordering between container apps that target the same environment — e.g. by adding `DependsOn` resource relationships that chain the apps in a single environment into a serial order.

This would let any model-graph-driven deployer serialize same-environment container app deployments without special-casing Azure Container Apps internals. The ordering is a real property of the target platform (the per-environment write lock), so modeling it in the environment/compute layer seems like the right home rather than expecting each downstream consumer to rediscover the constraint.

### Notes

- Serialization only needs to apply within a single managed environment; apps in different environments have no shared write lock and can still deploy in parallel.
- Other compute environments (AKS, App Service) don't have this per-environment write constraint, so this ordering should be specific to Azure Container Apps.
- Sequential deployment is already the effective behavior of `aspire deploy`; this request is about making the ordering explicit in the model so other deployment paths get it too. One such path is our internal EV2-based deployment pipeline, which builds an orchestration graph from the model and currently has to work around the missing ordering.

### Repro (sketch)

An AppHost with a container app environment and two container apps that do not reference each other:

```csharp
var builder = DistributedApplication.CreateBuilder(args);

var cae = builder.AddAzureContainerAppEnvironment("cae");

builder.AddProject("api").WithComputeEnvironment(cae);
builder.AddProject("worker").WithComputeEnvironment(cae);

builder.Build().Run();
```

The model contains no ordering relationship between `api` and `worker`, so a parallel deployer will attempt both container app writes against `cae` at once.