feat: Add canary version to standalone installers (#14908)
### Description
The standalone installers now accept `canary` as a version. Before, you
had to look up the exact canary version and pass it in.
```sh
curl -fsSL https://turborepo.dev/install | sh -s -- --version canary
```
`TURBO_VERSION=canary` works too, and so do `-Version canary` and
`$env:TURBO_VERSION = 'canary'` in `install.ps1`.
To find the version, the installer lists the 30 most recent GitHub
releases and picks the newest tag that matches `X.Y.Z-canary.N`:
```text
resolve version
"" or latest -> GET releases/latest (unchanged)
canary -> GET releases?per_page=30
first tag matching X.Y.Z-canary.N
none found: fail with "could not find a canary release on GitHub"
anything else -> use as an exact version (unchanged)
```
The installer reads GitHub releases, not npm's `canary` dist-tag. It
downloads the archives from the GitHub release, and npm can point to a
version before that release has its assets. The installer skips stable
tags, so it still picks the newest canary when a stable release came out
after it.
The installation docs get a short "Installing a canary release" section.
### Testing Instructions
I ran the changed POSIX installer against the live GitHub API in a clean
environment:
```sh
d=$(mktemp -d)
env -i HOME="$d" PATH=/usr/bin:/bin SHELL=/bin/zsh \
sh apps/docs/public/install --version canary --install-dir "$d/bin" --no-modify-path
"$d/bin/turbo" --version
```
The installer printed `Installed turbo 2.11.11-canary.1` and exited with
code 0. The installed binary reported `2.11.11-canary.1`, the newest
canary on GitHub at the time.
I did not run the `install.ps1` change or its new case in
`scripts/install.windows.test.ps1` locally. The Windows CI job is the
first run.