Rethink verbosity and developer experience for all commands

[nmetulev]

Today, most commands spit out a various log of work performed, spamming the output, even when verbosity is set to default. This makes it dificult to understand what each command does spams the console window.

To fix this:

1. all commands should print the bare minimum by default. A single line for most will be enough
2. We should use progress rings that show the details of work happening, and then clearing the details to indicate the work was completed
3. show relevant errors and logs only if something fails. if something fails, we should then hint to the user to run the command with more verbosity to get more logs or details

For example, the init command could have the following stages:

Init example

Starting initialization

> winapp init
  ✔ Created config file: D:\temp\cli-temp\app1\winapp.yaml
  ❯ Installing SDK dependencies (WinAppSDK, WindowsSDK, CppWinRT, BuildTools)
      ✔ Microsoft.WindowsAppSDK 1.8.251106002 downloaded
      ⠸ Downloading Microsoft.Windows.ImplementationLibrary

Once packages are downloaded

> winapp init
  ✔ Created config file: D:\temp\cli-temp\app1\winapp.yaml
  ✔ Installed SDK dependencies (WindowsAppSDK, WindowsSDK, CppWinRT, BuildTools)
  ❯ Generating C++/WinRT projections
      ✔ Generated C++/WinRT projections with cppwinrt
      ⠸ Copying headers to D:\temp\cli-temp\app1\.winapp\inlcude

Completed initialization

> winapp init
  ✔ Created config file: .\winapp.yaml
  ✔ Installed SDK dependencies (WindowsAppSDK, WindowsSDK, CppWinRT, BuildTools)
  ✔ Generated C++/WinRT projections in .\.winapp
  ✔ Created manifest: .\appxmanifest.xml
  ✔ Created dev certificate for package signing: .\devcert.pfx
  ✔ Installed Windows App Runtime
  ✔ Enabled dev mode
  ✔ Installed Visual Studio build tools
  ✔ Added .winapp and devcert.pfx to .gitignore
>

Commands that need to be updated:

• init
• restore
• pack
• update
• create-debug-identity
• node add-electron-debug-identity
• node create-addon all templates

[JesseCol]

We should use progress rings that show the details of work happening

Can we check to make sure progress rings are LLM friendly? It seems like progress rings would spam stdout a bit, taking up more tokens than we'd want. Maybe if it's a slow spin and at the end of the line it's OK.

[JesseCol]

I like your examples. I think you're implying another rule:

• When the tool makes some significant change to machine state or project, print a line the user can see.

Examples of significant change:

• Installed WindowsAppRuntime
• Downloaded something
• Changed a system setting like dev mode
• Wrote a file that's crucial to your project (winapp.yaml). (This one is a little harder for me to be sure about, seems like we could create some files silently)