Advanced brighterscript version picker

Once #583 lands, we should enhance with a few additional features:

1. pick a release line that will auto-update behind the scenes. Like this:

{
    "brightscript.bsdk": "insiders:lsp-rewrite",
    "brightscript.bsdk": "@latest",
    "brightscript.bsdk": "@next",
}

For any @ tag, we can fetch from the npm registry.

However, for the insiders builds, those may be coming from github actions, so we'll need to figure out how to best parse and present them based on the create-package tag.

2. Add ability to read this value from the package.json. I prefer the pattern "fromPackageJson:package.json", but here are other options we considered:

  "brightscript.bsdk": "sync:package.json",
  "brightscript.bsdk": "use:package.json",
  "brightscript.bsdk": "ref:./package.json",
  "brightscript.bsdk": "ref:./roku-app/package.json",
  "brightscript.bsdk": "get-version-from-package-json:./roku-app/package.json",
  "brightscript.bsdk": "readDependency:./roku-app/package.json",
  "brightscript.bsdk": "getFromPackageJson:./roku-app/package.json",
  "brightscript.bsdk": "readPkgVersion:./roku-app/package.json",
  
  "brightscript.bsdk": "versionFromJson:./roku-app/package.json",
  
  "brightscript.bsdk": "fromPackageJson:./roku-app/package.json",
  "brightscript.bsdk": "fromPackageJson:package.json",

Start by reviewing the version-picker work from #583 and the existing handling of brightscript.bsdk values. Check how npm registry tags and GitHub Actions create-package artifacts could be identified, then define the package.json reference syntax. Done means release-line tags and package.json-derived versions are parsed and presented consistently.