Support for github-package hosted extensions

Related to #16

GitHub packages now provides an NPM registry, which is a convenient way for orgs that are already operating within the github org infra to manage private packages.

There's a few caveats to this-

Github Packages are always scoped

From what I can tell, packages on this registry are always scoped, and explicitly map their owner back to the organization / owner.

Per #16 , this will be a stumbling block as VSCE and vscode don't support scoped extensions, however, per https://github.com/joelspadin-garmin/vscode-private-extension-manager/issues/16#issuecomment-1324500525 , it may be possible to work around this by publishing .vsix files with unscoped names to a scoped npm package
- I haven't tested this yet, there may be some code changes needed to vscode-private-extension-manager to support this, eg, mapping @organization-name/extension-name back to organization-name.extension-name
- The changes to this codebase would be minimal as most of what this extension does is leverage npm registry API's for discovery and metadata, then discover a file with the vsix extension attacked to a given package and install that.

GitHub only partially supports `npm` registry APIs

Although it supports:

querying and installing individual packages by name / scope,

It doesn't support:

npm's registry search APIs, which is what vscode-private-extension-manager relies on for discovery
Instead GitHub has it's own API for searching for packages, which likely already has wrappers in their node API client.

There's a few ways to deal with this -

Fetch certain extensions directly

This would apply to

Extensions in "recommendations" when populating discovery list
Providing a user command for installing extensions (related: #67 )

This should cover a lot of organizational use-cases without requiring this extension to support the GitHub NPM search API.

Add option indicating a registry should use github's api, and handle that for discovering extensions

I think this is probably a bit overkill, but essentially would involve adding first-class support for github's API, if a registry's config indicates it, eg an optional field "host_kind" : "github".

joelspadin-garmin / vscode-private-extension-manager