Track Deno support for TypeScript AppHosts

[sebastienros]

Summary

Split Deno follow-up work out of #15812 / #16162 so it can be evaluated and scheduled independently.

The original issue (#15812) mentioned both Bun and Deno, but #16162 intentionally shipped only npm/bun/yarn/pnpm. Feedback from @rickylabs in #16162 (comment) argues that a first-pass Deno implementation may be more incremental than originally described, especially for package.json-based projects.

Work to track

• Decide the first-pass scope:
  • package.json-based Deno support only vs. broader deno.json / task / import-map workflows
  • default permissions model for local AppHost execution and watch mode
• Extend TypeScriptAppHostToolchainResolver:
  • add Deno support to the toolchain enum and parser
  • detect packageManager: "deno@..." and decide whether to honor deno.lock, deno.json, and deno.jsonc
  • generate Deno execute/watch commands for AppHost execution
• Extend CLI dependency and doctor handling:
  • add deno metadata in CommandPathResolver
  • add missing-tool detection/messages/install guidance
  • teach aspire doctor how to report configured Deno toolchains
• Validate the scaffolding and acquisition story:
  • ensure aspire init / package.json merge / convenience scripts still make sense for the chosen Deno scope
  • decide whether Deno support needs any template or configurability changes
• Decide the initial debugging story:
  • confirm whether reusing the current V8 inspector / node launch capability is sufficient for a first pass
  • identify any Deno-specific launch/debug gaps that need to be addressed separately
• Add validation coverage:
  • unit tests for toolchain resolution, doctor checks, and missing-tool guidance
  • CLI E2E coverage for restore/run/doctor with a configured Deno toolchain
  • any Docker/CI image changes needed to exercise Deno in automation

Notes from the PR feedback

This follow-up should explicitly validate the main claims raised in #16162 rather than assuming them either way:

• Deno 2.x package.json / node_modules support may allow a package.json-based first pass
• the execute/watch command shape may be comparable to Bun for local AppHost runs
• the initial debugger story may be able to reuse the current V8 inspector path