Include `PortableCommandAlias` in `--commands` filter

Description of the new feature / enhancement

Currently the CLI filters packages with --commands option based on Commands: field in the manifest. However, many portable packages are packaged inside a nested archive, thereby utilizing the PortableCommandAlias field for symlinks / renaming the executable / representing the command of a package. The CLI should also include results from the PortableCommandAlias for the --commands option filter. (and maybe fallback to using the file name from RelativeFilePath if PortableCommandAlias is not specified? Though that can have its problems since portables can include a version string in their file name)

Example

Taking the example of junegunn.fzf

Current behavior

 ~ winget search --command fzf
No package found matching input criteria.

Expected Behavior

 ~ winget search --command fzf
Name   Id                 Version Match    Source
-------------------------------------------------
fzf    junegunn.fzf       0.45.0           winget

PowerToys Command Not Found Module

As reported by @SpecterShell on Element (who dug in and saw the code of this module here), the command not found module currently works based on invoking Find-WinGetPackage with the Command query parameter (and fallbacks to other methods if it cant find a package). As a result, it misses out on a lot of packages that don't have the Commands field in the manifest, but instead use PortableCommandAlias for the same purpose.

Proposed technical implementation details

No response

Start at the CLI entry point for the --commands filter and trace how manifest Commands fields are matched. Use the junegunn.fzf manifest's PortableCommandAlias and reproduce the winget search --command fzf example; done means the package appears in the results, while preserving the existing behavior for Commands.