Declarative description of DCP workloads

## Goal
The goal for this issue is to explore the possibility of describing DCP workloads via configuration and compare that with imperative approach exemplified by .NET Aspire. The used configuration should be very succinct for common cases, but allow arbitrary customization and automatic refinement of assets, in a way that is approachable by both developers and operations engineers.

## Rationale
The way DCP is used today (in Aspire) is *imperative*: the Aspire application host code creates the Aspire model, which then (for the purpose of local application execution) is translated into DCP model. This way of constructing the model has several benefits:

1. It is code, so pretty much any model transformation is possible.
2. Aspire uses C# as the native programming language for the application host and its runtime. C# is a modern language with rich facilities for extensibility, allowing for powerful and diverse "integrations" with numerous systems (databases, asynchronous communication facilities, caching facilities etc.)
3. C# is a general programming language that is familiar to a very large community of developers.

On the other hand, the imperative approach also has drawbacks compared to the "declarative" (configuration-based) way of describing the application model:

1. It is generally impossible to tell what the application host code will produce without executing it, and there is no guarantee that any two executions will produce the same result. Verification of the result (checking whether is satisfies required policies) is difficult.
2. It is difficult to process/enhance/adjust the application model via external tools.
3. C# is a popular programming language, but other languages (Python, JavaScript/TypeScript/Node, and others) are even more widely used in the ops world, and each language community has a number of its fierce proponents. Enabling access to imperative application models from variety of languages is possible, but not trivial and languages other than C# may never escape the "second class" stigma in Aspire.

In the last several years there have been an emergence of configuration languages and tools that attempt to combine the benefits of both declarative and imperative approaches, for example Cue https://cuelang.org/docs/concept/the-logic-of-cue/ and Hof https://hofstadter.io/. It would be interesting to explore if one of these configuration languages could be adopted for DCP to provide programming-language agnostic, verifiable way of describing application workloads that is close to expressiveness and familiarity that imperative description delivers.

Start by reviewing how the DCP API server and CLI currently represent workloads, then compare that model with the imperative .NET Aspire approach and the referenced Cue and Hof tools. Done means the project has an agreed direction for whether and how a succinct, customizable, verifiable declarative workload format should be adopted.

Written by the indexing model from the issue text.