Feature request: Turbopack plugin for bundleId injection + source map upload

## Summary

Add a Turbopack bundler plugin (sibling to the existing `@grafana/faro-webpack-plugin`, `@grafana/faro-rollup-plugin`, `@grafana/faro-vite-plugin`, `@grafana/faro-esbuild-plugin`) so Faro source maps work with Next.js projects that opt into `next build --turbopack`.

## Background

The Faro bundler plugins do two things in a single bundler pass:

1. **Inject a `bundleId` snippet** into each built chunk (via `faroBundleIdSnippet()`).
2. **Upload source maps** (via `uploadCompressedSourceMaps()` from `@grafana/faro-bundlers-shared`).

The upload half is now also available via `@grafana/faro-cli` as a post-build step (see #456), but the injection half still requires a bundler-native plugin — without the `bundleId` snippet in the emitted chunk, the Faro web SDK can't correlate runtime errors with the uploaded maps.

Today, Next.js `next build` still uses webpack by default, so `@grafana/faro-webpack-plugin` (or the rollup plugin used via the webpack `config.plugins.push()` hook as the kwenta project and others do) works fine. However:

- Turbopack is [stable for `next dev` in Next 15+](https://nextjs.org/blog/next-15#turbopack-dev-is-now-stable) and [approaching stable for `next build` in Next 16](https://nextjs.org/blog/next-16).
- Opting into `next build --turbopack` silently disables any `webpack(config, ...)` hook in `next.config.js`, which means Faro source map integration silently breaks — no injection, no upload, no error correlation.
- There is no upstream plugin today. Users either (a) stay on webpack for `next build`, or (b) lose source map support entirely when they migrate.

## What would unblock users

A `@grafana/faro-turbopack-plugin` (or equivalent mechanism) that:

- Injects the `bundleId` snippet into each emitted JS chunk during the Turbopack build.
- Exposes the same configuration surface as the existing plugins (`appName`, `endpoint`, `apiKey`, `appId`, `stackId`, `gzipContents`, `skipUpload`, …).
- Optionally delegates the actual upload to `@grafana/faro-cli` (post-build) while keeping injection in the bundler pass — the injection + upload can be separated here since the bundleId is already emitted and can be piped to the CLI via env var (`exportBundleIdToEnv()` pattern).

## Alternative if a native plugin is not feasible

Document the Turbopack limitation in the plugin's README + Faro source maps docs so users know to stay on webpack for `next build` until a plugin ships. A brief "Turbopack support status" table next to the existing webpack/rollup/vite/esbuild list would save a significant debugging round for anyone migrating.

## Context

This request comes from a Next.js project using `@grafana/faro-rollup-plugin` wired via the `webpack(config)` hook in `next.config.js`. We kept the webpack hook explicitly and added a comment documenting the Turbopack risk, but would much prefer to use an officially supported Turbopack integration once one exists.

Happy to help test a beta or provide a repro repo if that's useful.