API v2

Nobody has claimed this yet.

## Rationale
After shipping several Aspire releases we have learned enough, and accumulated enough outstanding, breaking-change work items, to develop a new version of DCP API.

## Must-have work items and issues

- [ ] Create v2 version of all current DCP resources and make all object kinds namespaced. This will allow us to use DCP as a long-running application orchestrator, supporting multiple application runs simultaneously.
- [ ] Make sure that all object references are using `NamespacedName`, or--if the referenced object kind can vary (rare)--that they use `NamespacedName` and `GroupVersionResource` combination. We mostly conform to this rule already in API v1 but not always, e.g. `ContainerExecSpec` refers to its owning `Container` by name only.
- [ ] Make sure all current integration tests have their v2 equivalent and are passing
- [ ] Account for, and report, all relevant network addresses for Services, Executables, and Containers (eliminate single "effective address" fiction) https://github.com/microsoft/dcp/issues/10
- [ ] Introduce a "physical" container resource/controller differentiated from the current "logical" container type https://github.com/microsoft/dcp/issues/11 An immediate benefit of doing this is logic reuse between Container and ContainerNetworkTunnelProxy controllers.
- [ ] Introduce a "process" resource differentiated from the current, logical `Executable` to be able to model Executables that are suspended under debugger/restarted after code change (watch mode). Relevant Aspire issue: https://github.com/dotnet/aspire/issues/9321
- [ ] Support for multiple networks https://github.com/microsoft/dcp/issues/18
- [ ] Resource change tracking https://github.com/microsoft/dcp/issues/34
- [ ] Add "container image" resource https://github.com/microsoft/dcp/issues/8
- [ ] Allow more than one ExecutionType to be specified for an Executable (to solve https://github.com/dotnet/aspire/issues/12522)

## Should-consider work items and issues

These are issues that should be considered when designing details of v2 API and may benefit from being implemented on top of the new v2 API (not supported by v1 API), but are not blocking with regards to shipping v2 API

- https://github.com/microsoft/dcp/issues/13
- https://github.com/microsoft/dcp/issues/30
- https://github.com/microsoft/dcp/issues/31
- https://github.com/microsoft/dcp/issues/32
- https://github.com/microsoft/dcp/issues/28
- https://github.com/dotnet/aspire/issues/12522
- https://github.com/microsoft/dcp/issues/77
- https://github.com/microsoft/dcp/issues/137
- [ ] Change `EnvVar.Value` definition to be a pointer, with the idea that if the pointer is nil, the presence of `EnvVar` record indicates the environment variable should be _removed_ from the process/container environment if present in the ambient environment.

Start by reviewing the current DCP API resources, object-reference conventions, and integration tests, then read the linked issues for networking, physical containers, multiple networks, change tracking, and container images. Done means a designed and implemented v2 covering every must-have item, with v2 equivalents of all integration tests passing.

Written by the indexing model from the issue text.