Add support for AppModel filter in templates and composition queries

[sibille]

For WinUI templates we need an additional parameter that allows filtering the templates by AppModel (Desktop + UWP).

The UserSelection has a group of context parameters (like language, platform, projecttype + frameworks) that are used to filter templates on the TemplateRepository. We should group them together so they can be passed together to make method signatures easier to understand and less error prone (when parameters are switched).

X-Ref: WinTS issue: microsoft/TemplateStudio#4040

[mrlacey]

Can this change be made in such a way that any future parameters needed by a referencing project don't need to be added to CoreTs as well?

CoreTs already knows more about the specific platforms of WinTS than it should (ideally it wouldn't need to know anything), so this would be a good opportunity to break the coupling.

[sibille]

I agree that we should find a way to define the UserSelection in the referencing projects and use something more agnostic in CoreTS.

I was thinking about having a generic UserSelection that holds the UserSelectionContext parameters in a key value dictionary and selected items in a list, with a property indicating the item type.
But that's a bigger change, that we need to study in detail.

A few thing we should look at would be:

• How can we ensure templates use the correct tags for the platform
• How can we convert UserSelections from referencing projects into the generic UserSelection used in CoreTS
• How can we validate UserSelections in CoreTS
• How can telemetry report be handled

[mrlacey]

• How can we ensure templates use the correct tags for the platform

This should be the responsibility of the template authors/consuming projects and the validation process they have there. CoreTS shouldn't care about this.

• How can we convert UserSelections from referencing projects into the generic UserSelection used in CoreTS

This will depend on how what the new option looks like.
If the new, generic option could be added in addition to the existing functionality this would allow for a staggered transition to the format.
The new format coudl be used for the new features that need it and existing templates can be slowly (and carefully) migrated over time. It would remove the need to change and modify everything at once so there's more time for testing and developing a process for automated conversion if one is needed.

• How can we validate UserSelections in CoreTS

What validation does CoreTS need to do beyond validating syntax and using the values provided? It shouldn't care about the values as they will vary based on different consuming projects.

• How can telemetry report be handled

Telemetry from CoreTS or the consuming projects?
I would hope that some mapping/adapter/translation could be done in either the reporting or sending of details.
Important to note.

[sibille]

I like the idea of adding a generic option to define properties, use this for the appmodel now and gradually migrate existing properties.

I'm exploring this option on a separate branch https://github.com/sibille/CoreTemplateStudio/tree/issue287_addpropertybag

[sibille]

Adding the appmodel to the propertybag works fine. I'll open a separate issue to gradually migrate other properties that depend on the platform as BackendFramework, FrontendFramework and ProjectType.