Use VS Code packaging for releases (#7721)

* Allow setting the VS Code build target

For the NPM package (and tests, at least for now), we will still use
linux-x64, but this is going to allow using the platform build targets
for our standalone releases so we can avoid having to copy all the
packaging steps (like cleaning up modules).

This does mean that the NPM package when installed will be missing those
cleanup steps.  Possibly we can try to break out the packaging step into
a something that can be ran standalone (which will also require
installing dev dependencies like gulp) but not sure how much work this
would be.

* Preserve dependencies for e2e tests

To avoid having to install them again.

Also moved an env block to the root of the  job.

* Refactor releases to use VS Code packaging

Instead of building the linux-x64 package, stripping the modules, then
installing them again, we build the correct target and use the modules
as they are.

This means we do not have to copy all the post-processing steps like the
ones that delete unnecessary modules.

For the NPM package we still publish the linux-x64 package (without
modules of course).  This means npm installations do not get that same
post-processing.

Another advantage of this is that we can run the release immediately
without having to wait for the build step, or on a commit that no longer
has a build artifact, since they all build individually now.  We could
try sharing the core-ci build step, but leaving that alone for now.

I also converted the macOS jobs into a matrix.

Deleted the CI readme because it was out of date and seemed to just
repeat what should be described in the scripts anyway.

Removed a section about Homebrew since we do not maintain that anymore.

It looks like there is no need to symlink node_modules.asar anymore.

docs/CONTRIBUTING.md

@@ -9,7 +9,6 @@
   - [Version updates to Code](#version-updates-to-code)
   - [Patching Code](#patching-code)
   - [Build](#build)
-    - [Creating a Standalone Release](#creating-a-standalone-release)
   - [Troubleshooting](#troubleshooting)
     - [I see "Forbidden access" when I load code-server in the browser](#i-see-forbidden-access-when-i-load-code-server-in-the-browser)
     - ["Can only have one anonymous define call per script"](#can-only-have-one-anonymous-define-call-per-script)
@@ -122,7 +121,7 @@ commits first if you are doing this).
 
 ### Build
 
-You can build a full production as follows:
+You can build a full production release as follows:
 
 ```shell
 git submodule update --init
@@ -130,26 +129,32 @@ quilt push -a
 npm install
 npm run build
 VERSION=0.0.0 npm run build:vscode
-npm run release
+KEEP_MODULES=1 npm run release
 ```
 
-This does not keep `node_modules`. If you want them to be kept, use
-`KEEP_MODULES=1 npm run release`
+You can omit `KEEP_MODULES` if you intend to use this in a platform-agnostic way
+(like for publishing to NPM), but since the VS Code build process does
+post-processing deletion of the modules, it is recommended to keep the modules
+when possible, since if you install them later you will have more than is
+required. `KEEP_MODULES` will also bundle Node and the code-server entry script.
 
 Run your build:
 
+```shell
+./release/bin/code-server
+```
+
+Or if you omitted `KEEP_MODULES`:
+
 ```shell
 cd release
-npm install --omit=dev # Skip if you used KEEP_MODULES=1
-# Runs the built JavaScript with Node.
+npm install --omit=dev
 node .
 ```
 
-Then, to build the release package:
+Then, to package the release:
 
 ```shell
-npm run release:standalone
-npm run test:integration
 npm run package
 ```
 
@@ -158,22 +163,6 @@ npm run package
 > If you need your builds to support older distros, run the build commands
 > inside a Docker container with all the build requirements installed.
 
-#### Creating a Standalone Release
-
-Part of the build process involves creating standalone releases. At the time of
-writing, we do this for the following platforms/architectures:
-
-- Linux amd64 (.tar.gz, .deb, and .rpm)
-- Linux arm64 (.tar.gz, .deb, and .rpm)
-- Linux arm7l (.tar.gz)
-- Linux armhf.deb
-- Linux armhf.rpm
-- macOS arm64.tar.gz
-
-Currently, these are compiled in CI using the `npm run release:standalone`
-command in the `release.yaml` workflow. We then upload them to the draft release
-and distribute via GitHub Releases.
-
 ### Troubleshooting
 
 #### I see "Forbidden access" when I load code-server in the browser