feat: launch independent services concurrently in up (#128)

[OrtegaMatias]

Summary

Fixes #128: up launched every service strictly one at a time, so N independent services paid N× the per-service start + readiness cost (the issue reports ~23s for 11 independent services). This launches each dependency wave concurrently — services with no pending dependency start together, while a dependent still waits for its dependencies.

Stacked on #144. The first commit here is that PR (the pure Service.dependencyLevels scheduler + its static tests). Please merge #144 first; this PR's second commit is the launch change that consumes it. Happy to rebase once #144 lands.

What changed

• Concurrent waves. The serial for target in project.services { try await configService(...) } becomes: compute Service.dependencyLevels(...), then for each wave run its services in a withThrowingTaskGroup, awaiting the whole wave before the next. A dependency cycle throws at dependencyLevels before anything launches, so it can never deadlock.
• LaunchState actor. Every piece of cross-service mutable state — container names, IPs, start states, health, console colors, and the IP-substituted environment — moves out of the value-type command and into an actor. Those dictionaries were previously mutated from the serial loop; launching a wave concurrently would race them, and the command's @unchecked Sendable hid that from the compiler. Routing all reads/writes through the actor makes concurrent launches data-race-free (compiles clean under -swift-version 6).
• Semantics preserved by the wave barrier. Because a wave fully completes before the next begins, a service's dependencies have always reached their state before it starts, so depends_on ordering and the service_started / service_healthy / service_completed_successfully conditions behave exactly as before. Foreground mode, one-shot exit-code handling, and the SIGINT/SIGTERM handler (installed after the group returns) are unchanged.
• --sequential opt-out. Restores the original one-at-a-time behavior.

Verification

The pure scheduler is unit-tested (in #144). The launch path needs the daemon, so it was verified end-to-end against Apple container:

scenario	result
8 independent services, --sequential	11.6s, 8/8 running
8 independent services, parallel (default)	6.1s, 8/8 running (~1.9×)
web → app → db chain, parallel	exit 0, comes up strictly db → app → web, 3/3 running

Full static suite stays green:

swift test --filter Container_Compose_StaticTests
✔ Test run with 242 tests in 22 suites passed

Notes / scope

• Within a wave, services are independent by construction, so cross-service reads (peer IPs for env substitution) only ever read already-completed earlier waves.
• The /etc/hosts cross-patch fallback (DNS-unavailable path) stays best-effort as before; its append is idempotent (grep-guarded).
• --no-deps is not affected (it doesn't exist today; selection still pulls transitive deps).