Proposal: simple context menu entries in app manifest

# Proposal: simple context menu entries in app manifest

## Summary
Support declaring a context menu entry with a specific icon, display name and executable in app manifest instead of requiring to provide an `IExplorerCommand` implementation.

## Rationale

* Currently, to have an entry in the new Windows 11 context menu (instead of the legacy Windows 10 menu, which shows up under "Show more options"), [one needs to implement `IExplorerCommand`](https://docs.microsoft.com/en-us/windows/apps/get-started/make-apps-great-for-windows#context-menus)
* This is needlessly complicated if the context menu entry is just a simple entry which launches the app executable with a certain command line argument (which I'd wager is *most* context menu entries out there, people who need more already have a shell extension).
* ~~It also requires implementing it in C++, as [C# and other managed languages are heavily discouraged by Microsoft for in-process shell extensions](https://docs.microsoft.com/en-us/windows/win32/shell/shell-and-managed-code) (and `IExplorerCommand` indeed [only supports in-process activation](https://docs.microsoft.com/en-us/windows/win32/shell/how-to-create-cascading-menus-with-the-iexplorercommand-interface#remarks)).~~
* ~~This will cause the DLL to be loaded in any process with a save as/browse dialog, causing potential runtime version conflicts. So, even if one disregards the MS recommendations and goes ahead with a managed implementation, this will cause problems in the real world.~~
* This means that, in practice, many projects might skip this altogether because of implementation complexity.

## Scope

| Capability | Priority |
| :---------- | :------- |
| This proposal will allow developers to register context menu entries that launch an app when clicked | Must |
| This proposal will allow developers to pass command line arguments including the selected file, if any, to the Win32 app | Must |
| This proposal will allow developers to activate UWP apps in response to a context menu entry click | Should |
| This proposal will allow end users to show/hide undesired context menu entries from the Settings app | Could |
| This proposal will allow end users to register their own context menu entries | Won't |

## Important Notes
The app manifest entry could look something like this:
```xml

Open folder in App

Do something

Do something but with Win32

Do something but with Win32

ms-resource:OpenFileVerbDescription

Edit file in App
Assets\EditFile.ico

View log file in App
Assets\ViewLog.png

Edit C++ in App

```

In command line arguments, `%1` is a placeholder for the file/folder name, if any.

One could then use activation APIs to determine if the app was launched in response to a context menu entry (or for Win32 apps, they can read command line arguments). It wouldn't be unlike the File activation API:
```diff
namespace Windows.ApplicationModel.Activation
{
public enum ActivationKind
{
+ ContextMenu = 1023
}

+ public sealed class ContextMenuTargetActivatedEventArgs : IActivatedEventArgsWithUser
+ {
+ public string ItemType { get; }
+ public string Verb { get; }
+ public IStorageItem? File { get; } // null if something like Directory\Background was activated
+ }
}

namespace Windows.UI.Xaml
{
public class Application
{
+ protected virtual void OnContextMenuTargetActivated(ContextMenuTargetActivatedEventArgs args);
}
}
```

Command line arguments are supported to simplify the migration of an existing Win32 app to MSIX, as the app might already have command line arguments for context menu entries and adding code checking for the activation kind is not possible or too costly. It's not needed for UWP/Windows App SDK apps, which use activation from the start.

## Open Questions
None that I can think of.

This is a feature proposal rather than a located implementation task; it names app-manifest context-menu entries, SimpleVerb examples, and activation APIs but no repository files or tests. Start by locating the manifest schema and activation API entry points, then define the supported schema and activation behavior and add coverage for the listed Win32, UWP, and target-type cases.

Written by the indexing model from the issue text.