Handlers schema for other features

Description of the new feature / enhancement

• Related to #1900
• Related to #1899
• Related to https://github.com/microsoft/winget-pkgs/issues/29323
• Related to https://github.com/microsoft/winget-pkgs/issues/100

Much of these ideas rely on information on how to handle the manifest information, or to provide additional information that isn't intended to be in the package manifest. These ideas are currently suggesting individual Yaml files for their implementation. However, it should be possible to have all of this information in a single Yaml file and have an associated schema.

This would reduce any potential clutter from having files on how the application and other integrations would behave.

If included with a manifest submission, should be accepted by the pipelines. If the handlers contain only Tombstones and Maintaner-Users, community mods could be able to approve. If the handlers contain a redirect, robots handling, or Maintainer-Approvers, add a specific label and assign to a MSFT engineer for review

Proposed technical implementation details

A handler file could look something like this, and would be valid at the package or version level. If there is a handler at the version level and the package level, both should be considered, and any conflicts should be resolved by giving preference to the version level handlers.

# Handlers.yaml
Redirect:
  Type: <redirect type>
     # soft - optional redirect 
     # hard - required redirect
  PackageId:  <New package identifier> # Where the package redirects to
Tombstone:
  # I know this is a single field, but should still be an object in case additional metadata needs to be added in the future
  Reason: <Why this version/package tombstoned>
    # Examples -
    # Download not available
    # Interactive only installer
    # Cannot be validated
    # Dynamic CDN
    # Publisher request
Maintainers: # 
  Users: # Who usually updates this package or has knowledge about it
    - jedieaston
    - OfficialEsco
  Approvers: # These people might be able to act as moderators for this specific package without being community moderators
    - Trenly
   Owners: 
    - Verified publisher metadata suggested from issue 100 linked above
Robots:
    SkipAvailabilityCheck: <whether wingetbot should check if this package is available>
    CheckInterval: <how often to check the urls>
    # This gets down to what the SLA is for keeping packages up to date. Maybe some packages only need to be checked for upgrade/ availability
    # once a day, maybe some only update once a week. Just something to consider for the future
    ManualUpgradesOnly: <if a new version is detected, create an issue and mention all the maintainers instead of having the bot try to update it>
    # Additional keys here to control how the repository bots interact with the package
ManifestVersion: <1.3?>

No implementation files or tests are named. Start by reading related issues #1900 and #1899 and the linked winget-pkgs issues #29323 and #100, then trace how manifest submissions are handled by the pipelines. Done requires an agreed handler schema, package/version precedence rules, and defined review behavior for each handler type.