DSC v3 in Windows Terminal

[denelon]

Description of the new feature/enhancement

I would like to leverage Windows Terminal a DSC Resource so I can specify the way I want Windows Terminal configured. WinGet Configuration could leverage a configuration file to set Windows Terminal up the way I want it.

Proposed technical implementation details (optional)

Some notes from discussion: Paths in the json file will be Hard. If someone's got a relative path in their settings.json, well, that just won't work on another machine.

The ideal case here is probably a dotfiles-like experience where we can DSC that folder of fonts, images, and settings.json.

Crawl

• We can install the Terminal.
• We can set one or two basic global settings (Theme for example).

Walk

• We can make some customizations to the settings.json. Maybe use a well-known URL to apply your settings.

Run

• We can also install fragment extensions the user already has.
• We can install distros, PWSH's etc.

Sprint

• We can export the current settings.json to a dotfiles-like folder, with images, fonts, etc, and re-write the settings.json to use that path

[zadjii-msft]

As discussed at Build last week:

• actions, schemes, themes: These are all pretty much machine-independent. (there may be minimal actions that reference profiles, but the 99% case should work fine).
• fonts out of profiles could be enumerated and included in the resource
• fragment extensions could also be enumerated and included in the list of dependencies
  • Similarly with PWSHs, WSLs, VS, and other dynamic profiles that we can enumerate
• profiles are very much machine-dependent.
  • As a crawl, we could just include them with no modifications
  • walk: include them, but with some property that indicates they've been migrated / restored somehow, and the user should manually fix them?
  • run: We could be smarter about "migrated" profiles, and default to some sensible CWD if we can't find the startingDirectory for that profile
  • sprint: When the user opens a migrated profile the first time, pop a dialog to confirm the choice of what the commandline & starting directory should be.
• newTabMenu is vaguely machine dependent, in the sense that it relies on the existence of profiles. But I think we're smart enough to leave entries that don't point at an existing profile out of the new tab menu. We may be able to migrate it wholesale with minimal concern for if the profiles in it migrated successfully.