[Settings, ListCommand] Add sort types, settings infrastructure, and CLI arguments for output ordering

[Madhusudhan-MSFT]

Summary

Add settings infrastructure and CLI arguments for configurable output sorting in
winget list. This lays the full type system, settings plumbing, and argument
registration without changing any runtime behavior — sort logic is wired in a
follow-up PR.

Part of #4238

Changes

Settings types and schema

• SortField and SortDirection enums: Add SortField (Relevance, Name, Id, Version,
  Source, Available) and SortDirection (Ascending, Descending) to the settings type
  system. Relevance preserves the current natural ordering and is publicly configurable
  (users can set ["relevance"] to explicitly opt out of sorting).
• Settings entries: Register OutputSortOrder and OutputSortDirection with typed
  validation using lowercase-once comparison (Utility::ToLower + ==). Default sort
  order is empty ({}) — an empty vector acts as a sentinel meaning "use context-aware
  defaults" (the follow-up PR's sort logic decides: relevance for queries, Name for
  no-query).
• JSON schema: Extend settings.schema.0.2.json with an output section containing
  sortOrder (string array with relevance, name, id, version, source, available) and
  sortDirection (string enum with ascending default).
• Static constexpr pattern: String constants for field name and direction comparisons
  follow the established static constexpr std::string_view pattern used by existing
  validators.

CLI arguments

• Execution args: Add Sort, SortAscending, and SortDescending arg types to
  ExecutionArgs.h.
• Argument registration: Define --sort (multi-use, max 7 values), --ascending/--asc,
  and --descending/--desc in Argument.cpp with resource string descriptions.
  --ascending and --descending are mutually exclusive via ExclusiveOf.
• ListCommand: Add the three new arguments to ListCommand::GetArguments().
• Resource strings: Add localized descriptions for all three arguments in
  winget.resw and resource IDs in Resources.h.

Impact

• No behavioral change — settings and arguments are defined but not yet consumed by
  any workflow. Existing winget list output remains unchanged.
• winget list --sort name is accepted without error but output remains unsorted until
  the sort logic PR lands.
• --ascending and --descending are mutually exclusive — passing both produces an error.

How Validated

• Unit tests: 17 test sections across SettingOutputSortOrder and SettingOutputSortDirection
  covering default values (empty fallback), single/multi-field, case insensitivity, empty
  array, relevance field, duplicate fields, invalid fields, mixed valid/invalid, and wrong
  JSON types (68 assertions total).
• Manual verification: wingetdev list --sort name accepted, wingetdev list --help
  shows new arguments.

Follow-up

• Sort logic wiring, query-aware defaults, and
  comprehensive sort tests will be in a follow-up PR.

[JohnMcPMS]

This includes the previous change, and I don't think there is enough in them to justify a split PR (and they have some shared portions, like which values are valid).

[Madhusudhan-MSFT]

Thanks John — understood. I split them as stacked PRs for independent scoping, but agree the change here is small. The latest PR1 fixes (shared ConvertToSortField, empty-vector default, public relevance) have been rebased into this branch.

[JohnMcPMS]

I don't see a shared function here or in the other PR. Can we just close one of the PRs?

[Madhusudhan-MSFT]

Sorry for the confusion — ConvertToSortField was in my local changes, I forgot to publish it to this PR. I was planning to include it as part of the follow-up PR that wires in all the actual sort logic. I've included it now (commit 3d9c1e4). I've also closed the other PR (#6176) so everything is in a single PR.