Add support for discovery extensions

[SteveL-MSFT]

PR Summary

• Add new subcommand to dsc to list extensions: dsc extension list
• Add new ExtensionManifest which is similar but differs from ResourceManifest. Only discover capability currently supported.
• Enhance existing discovery code to handle both resources and extensions. This includes pre-discoverying extensions when discovering resources since an extension may participate. This included a new enum to handle returning either resources or extensions.
• Write extensions as table when used interactively
• Rename existing functions to generalize for both resource and extension use, this also required making some private functions public

The output from a discovery extension must match:

{ "resourceManifestPath": "<absolute path>" }

PR Context

Fix #681

[michaeltlombardi]

Currently, the implementation requires returning the absolute path to a resource manifest - but I
can already see use cases for discovering extension manifests. For example, I might have
installed an extension from WinGet, and need to discover that, too.

Right now, it expects JSON like this:

{"resourceManifestPath":"/foo/bar/baz.dsc.resource.json"}

But we could have it return this, and parse the last segment of the path to determine kind:

{"absoluteManifestPath":"/foo/bar/baz.dsc.extension.json"}

Or require it return either resourceManifestPath or extensionManifestPath.

If we support extensions discovering extensions, we would need to recursively handle extension
discovery.

[michaeltlombardi]

Recommend naming this either Manifest or DscManifest to avoid adding another instance of Resource to our lexicon.

[SteveL-MSFT]

I was having a hard time coming up with a name that was more general, but just Manifest is not correct, but DscManifest given the suffix indicates it's a manifest, but it actually represents the actual resource or extension.

[SteveL-MSFT]

I think we can defer extension discovery til when we need it