cli: automatically use distro qualities if available

[connor4312]

A fully-functioning CLI with tunnel capabilities requires product-specific configuration that is not included in the OSS. This change has the CLI's build script automatically look for a peer vscode-distro folder and, in a debug build, set its build variables based on that, to make development easier.

It also works to set correct variables if vscode-distro is not found, based on the OSS product.json (though this is not sufficient to run a fully fledged tunnel.)

[aeschli]

@connor4312 I'm not a fan of that solution of adding knowledge of vscode-distro to the build scripts and accessing it via ../vscode-ditro.
One problem is that we can't just take whatever is checked out in ../vscode-distro but we need the distro commit as specified in package.json.
Second is that @joaomoreno is working or refactoring the way distro is mixed in. The build scripts in OSS should not depend on that, They just use the product.json available in the repo root.

I think, if we need to add knowledge about other qualities, we should add it to product.json, in tunnelApplicationConfig (for now). @joaomoreno wanted to chat about that (he might be on vacation right now)

[connor4312]

One problem is that we can't just take whatever is checked out in ../vscode-distro but we need the distro commit as specified in package.json.

I think this is mostly up to the developer, if they see functionality not working then they should check distro is synced correctly. But the developer might also want to test or verify changes in distro on a commit different than what's in the package.json. I kind of viewed this as a 'special' config similar to the optional install of the vsda dependency.

I think, if we need to add knowledge about other qualities, we should add it to product.json, in tunnelApplicationConfig

We depend on a sizable amount of information about other qualities since any given install of the CLI must interact with them. The six win32*AppId properties, nameLong, applicationName, serverApplicationName, and downloadUrl from each quality are currently mixed into the CLI. I don't think it is a good idea to duplicate this information inside every tunnelApplicationConfig; that could get out of sync and broken very easily.

Also, as mentioned in DM, when developing the CLI I do not want to have to make local product.json changes to produce a usable build, since it is very easily to accidentally commit those changes. I would be very happy to hear other alternative development solutions 🙂