Update `dsc resource list` output schema to include `methods`

[michaeltlombardi]

Summary of the new feature / enhancement

With the implementation of #309 in #314, users can now see which methods a resource supports when they run dsc resource list with the default view. However, if they capture the output or use an alternate format, this information is lost as it isn't part of the actual output object.

As a user and integrating engineer, I want to be able to quickly check which methods a resource supports in a script or function, so that I can make decisions about how to process that resource further.

Proposed technical implementation details (optional)

1. Add the methods field to the DscResource struct in dsc_lib/src/dscresource.rs as either a vector of strings or enumerations that map to the valid methods.
2. Move the logic for defining the methods field surfaced in the table from the List subcommand in dsc/src/subcommand.rs to the load_manifest function in dsc_lib/src/discovery/command_discovery.rs.
3. Update the source schema for the output object in schemas/src/outputs/resource/list.yaml to include the methods property.
4. Regenerate the compiled schemas from updated source. This change does not require an update to the canonical schema URI, as it's backward compatible.

[SteveL-MSFT]

The source of truth for that information is from the manifest which is nested in the resource json/yaml. The table view is a convenience, but I can see it has a similar problem we have in PowerShell which is a column header may not be a property on the object. We could do the same as in PS7 and italicize Methods and doc it rather than adding a property that just pulls the info from somewhere else that is already on the object.

[michaeltlombardi]

The source of truth for that information is from the manifest which is nested in the resource json/yaml.

That's also true for the version, type name, and description, I think. My understanding is that moving those keys to the top level of the return object is to make it easier for users/integrating tools to process and surface the information.

The other consideration is for adapted resources, like from PSDSC - in that specific case, the resources all (currently) implement the same methods, but in the future they may support export or use synthetic testing instead of implementing the test method. Right now, adapter resources aren't required to return manifests for the adapted resources from their list command.

[SteveL-MSFT]

This is addressed calling them caps for capabilities