CLI: Implement self-updating mechanism for Darklang's executable

[OceanOak]

We need to implement a self-updating mechanism for Darklang's executable. This self-update should enable the executable to check for updates upon launch, download the update if available, and apply it without interrupting the user's workflow.

Proposed solution:

When the user launches Darklang's CLI, a self-update process should run in the background:

• integrate the self-update functionality directly into the darklang executable, no need for a separate self-update script
• Version Comparison: The script should first compare the user's current version of Darklang with the latest available version.
• Download Update: If the user's version is not the latest, download the new executable, ensuring compatibility with the user's OS and architecture.
• Apply Update: After the download, the script should safely replace the old executable with the new one.
• The .darklang directory should exist; it contains backups, etc.

Upon corruption or other issues, it is okay if the user has to reinstall the exe or perform any necessary actions to fix it

In addressing this issue, we also need to:

• Build binaries for remaining runtimes ( osx-x64, osx-arm64, win-x64, and win-arm64)
• Handle self-update for windows
• Handle different shells (bash)
• Create single-line installation instructions: users should be able to type darklang in terminal and have it run, without cding to some directory

[OceanOak]

Notes from discussions on Discord regarding improvements to be made after the merge of #5276. (to organize/turn to todos)

• Build a Builtin.Tracing.log

All of these Builtin.printLines are making me think we should built a Builtin.Tracing.log thing instead, allow users to choose how their app should be traced, and log to a file or something instead, if so configured.
(mostly, anticipating these printLines breaking the LangServer, run by the CLI runtime)

• Include a --skip-self-update flag when running the lang server via CLI

When we're running the lang server via CLI, we should (for now) include a --skip-self-update flag or something, to prevent the self-update dance, so we don't hit those logs

• Look into long-running services

• (currently) every time we run a command, we 'start the CLI' -- there's no long-running service yet, that hangs around. (though there will be, probably)

• Better handling for the language server failures

if the langserver fails, it fails, and someone can reload the extension. Not a big deal in the short term. Just want to make sure that circling back to this is on a list somewhere

• Recheck the implementation of Process.Result

• To check: I'm not totally sold on our Process.Result type - it's just stderr, stdout, and exitCode -- I find it a bit annoying to have to check the exitCode for each Process.run.

• Publish build for windows, and handle self-update

define a type Host = | Windows of Architecture * ... | Linux of Arch * ... | MacOS of ... and pass that Host into the helper fns

• Ensure we are following best practices when installing/running the cli for the first time

  • When the self-update occurs, we don't switch to using the new version that is located in the .darklang/bin/darklang. Instead, the next time the user runs the 'darklang' command, it references the new version (is this ok?)
  • We redownload the latest version when the user first runs the executable, because the self-update runs and since the config file is freshly created it thinks that the executable is not up-to-date, leading to a re-download)

• Improve installation logs and error messages

• Improve error messages : I suppose that should say "couldn't fetch details of the latest darklang release" approx
  Maybe with a preamble of "issue occurred when trying to self update:"

• one idea I had would be to have the output be something like
  Running self-update...

  • fetching list of releases
  • ...
  • ...
    Now, processing normally
    Just something to visually divide the operations

[StachuDotNet]

At this point, the goal of this Issue has been accomplished! I've extracted remaining notes from here into other issues (mostly the main CLI Runtime one)