Add dark/light theme DSC resource

[Gijsreyn]

Summary of the Pull Request

This pull request teaches Windows Terminal to speak Microsoft DSC. It adds a small new console tool (TerminalDsc.exe) that ships inside the Terminal package and serves DSC resources. The first resource is: Microsoft.WindowsTerminal/Settings, managing three global settings: theme, copyOnSelect, and initialCols. With this in place, you can put your Terminal theme in a DSC configuration document and apply it with dsc.exe.

Because Microsoft DSC uses a discovery extension (appx), the resource manifest file can be found. That means that this needs to be shipped in the MSIX.

References and Relevant Issues

• #15862 — DSC in Windows Terminal (this is the "one or two simple settings, starting with theme" milestone from the discussion there)
• Architecture is modeled after multiple RDK designs in the Microsoft DSC landscape
• DSC discussion about DSC across Microsoft tools

Detailed Description of the Pull Request / Additional comments

The PR initially was a little smaller, but the goal wasn't just "make the theme settable." It was to build a little home where more resources can move in later without remodeling. The pieces that are put under src/cascadia/TerminalDsc/ are stepped through step by step:

1. Everything starts in main.cpp. It creates a ResourceRegistry and registers every resource this executable serves, with one registry.Add(...) call per resource.
2. During registration, the registry looks at the resource type at compile time to see which capability interfaces it implements (IGettable, ISettable, ITestable, IDeletable, IExportable, all declared in Resource/DscResource.h). A resource says what it can do simply by deriving from them. The repo builds without RTTI, so this uses templates instead of dynamic_cast.
3. CommandBuilder parses the command line (TerminalDsc <get|set|test|delete|export|schema|manifest> [--resource <type>] [--input <json>]), finds the right resource in the registry, and hands the work to ResourceExecutor. That one speaks the protocol: desired state comes in through --input, actual state goes out as one compact JSON line, and Logger writes diagnostics as {"info": "..."} or {"error": "..."} lines on stderr, which is how DSC likes them.
4. ManifestGenerator builds the DSC manifest from that same registry, so the manifest can never quietly drift from what the code actually does. TerminalDsc.exe manifest --save regenerates the checked-in file, and a unit test fails if the two ever disagree.
5. The first real resource lives in Resources/Settings/. It reuses CascadiaSettings::LoadAll() and WriteSettingsToDisk(), so a DSC set goes through the exact same code path as the Settings UI, including settings hot-reload in running windows. Each managed setting is one row in a small property table (reader, writer, schema fragment). Nothing in Resource/ knows about Terminal settings

Adding the next resource (color schemes? profiles? 👀) works like this:

1. Make a Resources/<Name>/ folder and implement IDscResource plus the capability interfaces you want.
2. Register it with one line in main.cpp.
3. Refresh the checked-in manifest with TerminalDsc.exe manifest --save.

The framework picks it up from there.

Validation Steps Performed

PR Checklist

• Closes #xxx
• Tests added/passed
• Documentation updated
  • If checked, please file a pull request on our docs repo and link it here: #xxx
• Schema updated (if necessary)

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.