[std] Add utility to decompress plain `.gz` files

[kylewlacy]

This topic came up in another issue: #336 (comment)

Today, we have an unarchive method, which supports unarchiving .tar, .tar.gz, .tar.bz2, .tar.xz, .tar.zstd, and .zip files. In the aforementioned issue, we saw a case where, for Deno, we wanted to decompress a plain .gz file-- not an archive.

To resolve it, we manually decompressed the .gz file using std.runBash and the zcat utility:

std
  .download({
    url: "https://github.com/denoland/rusty_v8/releases/download/v135.1.0/librusty_v8_release_x86_64-unknown-linux-gnu.a.gz",
    hash: std.sha256Hash(
      "406a453645473bd8f8b9a818342e57dc95627fcd1155ace9eb7a2aadd5985285",
    ),
  })
  .pipe((gzip) =>
    std.runBash`
      zcat "$gzip" > "$BRIOCHE_OUTPUT"
    `
      .env({ gzip })
      .toFile(),
  );

We should provide a built-in way to go from a .gz file to the raw decompressed form as a utility within std. Just like with the existing .unarchive() method, we should also make sure it takes the compression format as an input, so we could add more compression formats over time.

[kylewlacy]

This feature leaves the door open for a lot of bikeshedding! I'll lay out my initial impressions, but definitely open to other ideas/suggestions:

Interface: Add as a new standalone std.decompress utility

Rather than updating the existing .unarchive() method, I think it makes more sense to use a separate utility. For one, the current .unarchive() method always returns the type Recipe<Directory> today, whereas decompressing a file should return a Recipe<File>. We could use an overload signature or conditional types to infer the right return type based on the first argument, but it definitely keeps the interfaces simpler if they're separate. And from a very pedantic perspective, a compressed .gz file is not itself an archive, so that's maybe also a hint that a different name makes more sense.

Decompressing a non-archive file is pretty rare it seems, so I think a standalone utility makes sense. Adding new Recipe methods is effectively a breaking change to std, so I lean towards adding new features as free functions except very frequently used utilities.

So I'd suggest this interface:

export function decompress(
  file: std.RecipeLike<std.File>,
  format: CompressionFormat
): std.Recipe<std.File>;

Implementation: Use std.process (for now)

The Brioche runtime has built-in support for the unarchive recipe, but for plain decompression, I'd rather use std.process to implement it, at least as a first pass. New built-in recipes depend on a new Brioche release first, so it takes a lot of churn to use new recipes.

Fundamentally, the only reason Brioche itself even has unarchive as a built-in recipe is because we need to unarchive several downloads as part of the bootstrapping process. That is, to build tar and gzip at all, you already need to be able to decompress a .tar.gz file containing their sources! We don't have a need for plain decompression without unarchiving as part of the bootstrap process.