suggestion: make `@std/http` utilities cross-runtime

**Is your feature request related to a problem? Please describe.**

I would like to use [`@std/http/negotiation`](https://jsr.io/@std/http/doc/negotiation) in Node using pnpm. `negotiation` is entirely self-contained, but jsr marks the whole `@std/http` module as Deno- and Bun-compatible only.

From a cursory look, most other utilities in `@std/http` (cookies, user_agent, status, server_sent_event_stream, ...) are also self-contained.

The dependencies for `@std/http` are from:
- [unstable_signed_cookie](https://github.com/denoland/std/blob/main/http/unstable_file_server.ts) depending on `@std/encoding`
- [etag](https://github.com/denoland/std/blob/main/http/etag.ts) depending on `@std/encoding`
- [unstable_file_server](https://github.com/denoland/std/blob/main/http/unstable_file_server.ts) depending on `file_server` (below)
- [file_server](https://github.com/denoland/std/blob/main/http/file_server.ts) imports all the rest: `@std/path`, `@std/fs`, `@std/media-types`, `@std/streams`, `@std/cli`, `@std/fmt`, `@std/net`, `@std/html`, and `./etag` above

There has been efforts in making some `@std` modules cross-runtime compatible (but from what I could find there is no global guideline on that):
- https://github.com/denoland/std/issues/6255 (currently pinned)
- https://github.com/denoland/std/issues/4313 (referenced in the above)
- https://github.com/denoland/std/issues/6164
- https://github.com/denoland/std/issues/4914
- https://github.com/denoland/std/issues/4600

(search keywords: "cross-runtime", "node compatible")

The dependency graph in that last issue is relevant here:
`http` was the "widest" package dependency-wise, mostly from `file_server`.

The specific utility I want to use (negotiation) has been adapted from `npm:negotiator`, which has an open issue for migrating it to ES6: https://github.com/jshttp/negotiator/issues/71. Since the work has already been done here, being able to use `@std/http/negotiation` from any runtime would also solve that issue.

**Describe the solution you'd like**

Some obvious solutions would be to split `file_server` to it's own module, or abstracting the Deno-specific APIs like what has been discussed in https://github.com/denoland/std/issues/4313.

If it's possible to "install" a specific path inside a module like `@std/http/encoding` from other package managers (I use pnpm), that'd work too. I couldn't find anything about that (I don't know the right keywords to search for), but I assume this has been considered and decided against, since running `deno add jsr:@std/http/negotiation` installs `jsr:@std/http`. Doing `pnpm i jsr:@std/http/negotiation` errors with a 404.

Having a blessed path to vendor specific files or functions (either from `@std` or from jsr generally) would also solve it for me. But I figure that'd be very package-specific and couldn't be generalized without a lot of tooling work. (I couldn't find much about vendoring related to jsr or `@std`.)

**Describe alternatives you've considered**

My current solution is to simply manually vendor the functions that I need. Ignoring `file_server`, this also avoids me the dependency on `@std/encoding` (from `etag` and `unstable_signed_cookie`) which I don't use.

I have considered using vendoring tools ([vendorpull](https://github.com/sourcemeta/vendorpull), [vendir](https://github.com/carvel-dev/vendir), [git-vendor](https://github.com/thejoshwolfe/git-vendor)), some of which have options to pick specific files or ignore other paths.

Simply installing the whole http module via `pnpm i jsr:@std/http` also works (even if the [module's jsr page](https://jsr.io/@std/http/doc/negotiation/~/acceptsLanguages) doesn't show the `pnpm` option). Given that I don't use file_server, I won't hit the Deno-specific code. But this makes me pull 11 transitive dependencies that I don't use.

Assumedly I focus a lot on reducing dependencies. I understand that it might not be a goal or focus for everyone (or for jsr, or for `@std` — especially since the dependencies are on other `@std` modules only!)

---

Thanks for your time (and for the work on `@std`)!