Replace TerminalSettings runtimeclasses with interfaces only

[DHowett-MSFT]

TerminalSettings.dll exists because it is difficult to coerce the C++/WinRT build infrastructure to produce a type library and a set of headers without either statically linking (which rolls up the generated types into the consuming project) or dynamically linking (which forces us to put a DLL on disk).

I posit that the ideal representation of settings is the ICoreSettings and IControlSettings interfaces only. No classes need to be implemented in TerminalSettings.dll, because all they'd do is ferry data back and forth.

By dropping the classes and switching to the interfaces, we can remove the setters from the interfaces, and remove the runtime classes completely. Cascadia (or TerminalApp::<something>) can implement ICoreSettings and IControlSettings as views over existing profile data.

This will reduce both the number of runtime hops required for loading and saving settings and the number of code authoring hops required for adding new settings.

Approach

• Introduce/Move TerminalApp bridge #7139: Introduce/Move TerminalApp bridge
  • Move TerminalSettings::TerminalSettings to TerminalApp::TerminalSettings
• Move TerminalSettings interfaces #7140: Move TerminalSettings interfaces
  • Move TerminalSettings::ICoreSettings to TerminalControl project
  • Move TerminalSettings::IControlSettings to TerminalControl project
• Transform TerminalApp settings objects into WinRT objects #7141: Transform TerminalApp settings objects into WinRT objects
  • Profile
  • ColorScheme
  • GlobalSettings
  • Keybindings (this may be moved out to be its own PR)
• Move the new WinRT settings objects into TerminalSettings project
  • I'll close the scenario when this is complete

[zadjii-msft]

So that's what I tried initially. However, the TerminalCore project is a non-cppwinrt static lib. This was done to avoid having dll hops between TerminalCore and TerminalControl, which I believed would be frequent. Because TerminalCore wasn't a cppwinrt project, it couldn't generate a winmd/header pair for the idl.

Trying to make it a cppwinrt static library also introduced it's own insanity of build errors, where sometimes the winmd would be double included, or not included at all.

You also can't have a cppwinrt project that only has interface definitions without defining at least one type. I don't know if that was resolved in cppwinrt 2.0 or not. I tried this initially by making a TerminalSettings project that only included two idl files, but somewhere up the tree, msbuild was not be happy about the fact that the project didn't generate a dll (since it had no code, it didn't build a dll).

[DHowett-MSFT]

Indeed. I'll mark this help-wanted; I know that it's possible to have a project that only produces a type library, we just might need to dig deep on build system arcana.

[DHowett-MSFT]

Notes: I think it's okay that TerminalCore wouldn't be a C++/WinRT project. Since it does live on the "fully C++" side of the world, it wouldn't be unreasonable for it to use wil::com_ptr over the raw interface types in the ::ABI namespace that MIDL generates. It might even be preferable... the annoying thing is unpacking HSTRINGs, but even that really isn't all that bad.

It can also become a C++/WinRT consumer very easily. It's significantly cheaper than authoring components, and it is the recommended way to consume all WinRT APIs in all C++ code.