Compress envelopes in the browser SDK with `CompressionStream`

Today the browser SDK sends every envelope **uncompressed** over `fetch` ([`packages/browser/src/transports/fetch.ts`](https://github.com/getsentry/sentry-javascript/blob/develop/packages/browser/src/transports/fetch.ts)). Relay already accepts `gzip`, `deflate`, `br`, and `zstd` on the envelope endpoint, so this is a pure SDK change.

We could gzip envelopes in the browser using the native [`CompressionStream`](https://developer.mozilla.org/en-US/docs/Web/API/CompressionStream) API, with graceful fallback to the current uncompressed path.

`CompressionStream('gzip')` is [supported by ~95% of global traffic](https://caniuse.com/mdn-api_compressionstream), with potential gaps for us:

| Browser | Supported since | Matches Sentry v9+ floor? |
|---|---|---|
| Chrome / Edge 80+ | Feb 2020 | ✅ |
| Firefox 113+ | May 2023 | ❌ (Sentry floor is FF 74) |
| Safari 16.4+ / iOS 16.4+ | Mar 2023 | ❌ (Sentry floor is Safari 14) |

But the cool thing is we could just fallback to today's behavior, so it's a progressive enhancement and degrades very gracefully (literally what we have today).

To avoid compressing tiny payloads we can only do it if the payloads pass a certain threshold (1kb?).

### Caveats

A few problems and hiccups to handle would be:

- Our tests assume data is json readable directly, so we will need to uncompress them if we were to test his, alternatively we can disable it for tests and only have a handful of tests that test the compression. I prefer the former because it would represent real world behavior/adoption.
- This affects our tunnel project, payloads are assumed to be plain so adding a layer of compress/decompress/compress again will waste resources and may not be worth it.