Document the behavior of monikers and search prioritization

So, tell me, what is the moniker definition for in the manifest if it is not intended to act as a shorthand for a package ID? I repeat, monikers should have the highest priority in selecting a package. Tags are for searching. I have no quarrel with the search results. My problem is with the install (and show) results.

Originally posted by @Jaifroid in https://github.com/microsoft/winget-cli/issues/1523#issuecomment-956749936

I'm just breaking this out into a separate issue because I'm interested in the full answer too.

IMO, counter to the current logic, I think the prioritization should be ID -> Moniker -> Name. I would expect a user to most likely know dotnet-runtime, followed by Microsoft.dotnet.5.x64, followed by ".NET 5 Desktop Runtime NT (64-bit) (for legacy PCs)" or whatever the ARP name is. Of course, the PackageName business will be cleared up with v1.1, but you understand my meaning. (The ID should go first just to be able to disambiguate quickly, even though most users do not know it).

I also do not think that we as users should have to prioritize the sources by hand. That's not how APT or yum do it, (they just take the highest version number), that's not how npm does it (it makes you namespace your sources if you want to select between them), and I think that will be really confusing to control for both users and administrators.

(These are just my opinions. There's probably problems with this.)

No file, test, or entry point is named. Start by locating the code and existing documentation for monikers, package IDs, names, search, install, and show prioritization. Done should clearly document the current behavior and resolve or explain the proposed priority and source-selection questions.