Add Store source support.

[DrewNaylor]

Support for multiple sources and a way to load manifests that aren't in an easily-accessible zip file are prerequisites for this feature. Maybe the Store source's package details can be loaded only from the database until there's a way to load the manifests from the files on the server. Of course, the "loading from the server at runtime" would have to be optional, as would Store support. Until there's a way to load the description from the server, people would have to show the package in winget to get the description and other details not in the database. Tags should also be pulled from the database, as winget doesn't show them and I think it would be useful.

[DrewNaylor]

Turns out that the Store source is now a REST source, and here's the information page for it:
https://storeedgefd.dsx.mp.microsoft.com/v9.0/information

Proof that it's a REST source is in the logs in these issues:
microsoft/winget-cli#1664
microsoft/winget-cli#1812
Found this comment too while I was trying to find other stuff:
microsoft/winget-cli#1562 (comment)

I'm going to have to have a way to ask the user if they wish to accept the terms of using the MSStore source. By default it'll be set to False, and the user will have a chance to say whether they accept the terms of using it on starting guinget for the first time. If they say yes, then the user will have access to the Store source automatically. If they say no, they'll not have access and the Store source will be turned off, as expected. However, if at any time the user wishes to use the Store source, they can go into the sources manager and check a box that says that they accept the terms of using the Store source after checking a box to use the Store source. They'll be able to turn it off whether they accept the terms or not, just to make it simpler. If they wish to revoke their acceptance of the terms and say that they don't accept them (I hope this is legally possible), then they'll be able to go into the sources manager and uncheck the checkboxes that say they accept the terms and that they want to use the Store source, in that order, because the terms checkbox is indented within the one that says whether to use the Store source or not.

I need to add that there'll be a link to the terms of service for sources below the checkbox to accept their terms, if that source has terms of service. If it doesn't, then there won't be a checkbox to accept terms, and no link.

Using the sources manager app for this will allow any other sources that have terms of use to be added and used. Asking the user if they accept the terms of using a source will be done when adding a source (if it has a terms of use), as well as when parsing enabled sources when refreshing the cache (if there are any sources that haven't had their terms of use accepted yet). Maybe there should be a window that lists the sources that need to have their terms accepted along with a link to their info page and the terms themselves, kinda like when you update NuGet packages in Visual Studio. We'll ignore disabled sources.

Before it's possible to add other sources, I'll have to move the current source to be loaded from a YAML file on the disk:
#49

[DrewNaylor]

Here's an example manifest:
https://storeedgefd.dsx.mp.microsoft.com/v9.0/packageManifests/9NBLGGH4QWNX?Market=US

Example screenshot:

Not sure how to use it as an api. Maybe I'll have to cross-reference with the example here:
https://github.com/microsoft/winget-cli-restsource/tree/main/documentation

Also not sure if I'll have to support all the versions or just the latest one when I add the support. If possible, supporting multiple versions may be a good idea just so that it's fully compliant with anything someone wants to use.

Something I need to keep in mind is that the rest of the stuff under agreements besides terms need to be shown, as they're also used for seizure warnings and Store license terms, for example. Noticed that they're also used to say what a package's category, pricing, and free trial existence status is.

[DrewNaylor]

Maybe this should be delayed to v0.5 because I really want to get the faster and more-efficient package list update out as soon as possible. It's really bothering me how slow it is right now.