Attach tarball as readonly file system

### What problem are you trying to solve?

As we migrate to deno.com we have a number of legacy sites that are built using a variety of technologies: Jekyll, Gatsby, Docusaurus. We'd like to be able to serve these directly from a root site on deno.com along side each other, and along side a site built with Fresh. However, we'd prefer not to gum up our git repo with a bunch of pre-built, static HTML files, and every time we update one of the legacy sites

### Describe the solution you'd like

I'd love to be able to "attach" a tarball as a read-only volume that you can then use with [serveDir()](https://deno.land/std@0.203.0/http/file_server.ts?s=serveDir) That way, the new site can exist alongside (and proxy where needed) the old sites, but we can build the old sites separately in their own repositories, and use a GitHub action to create a release or upload to S3 or some other CDN. Then, we can tell our application in deno to attach the tarball at the given URL.

The new site can remain lean, mean, and just be focused on the modern way of development.

### Describe alternatives you've considered

One option is checking in the pre-built sites to the repository. While it works, it's really inconvenient in that it generates a lot of commit noise. The thought of it feels sad.

What we do currently is we download the tarball, unzip it, and serve it from memory. To do this, we copied (roughly) the code from [file_server.ts](https://deno.land/std/http/file_server.ts). You can find it here https://github.com/thefrontside/effection/blob/v3/www/lib/serve-tar.ts

### Documentation, Adoption, Migration Strategy

I would imagine this would be similar to the environment variables functionality found at:

`/projects/${projectName}/settings`

There would be a section called "Volumes" and when you click "Add Volume" you're prompted for an `name` and a `URL`. The name should be a reasonable unix directory name (for some definition of reasonable) and the url should be a url. It could then download the archive, verify it, and make it available to your application as something like `/volumes/${name}`.

In a similar vein, you could do the same via `deployctl`:

```
$ deployctl attach PROJECT_NAME VOLUME_NAME VOLUME_URL
```

So in our real world situation where we're using the in-memory tarball, it might look like:

```
$ deployctl attach effection v2-apidocs https://github.com/thefrontside/effection/releases/download/docs-v2-r4/docs-v2-r4.apidocs.tgz
```