Respect user-provided sourcemap generation settings

[Lms24]

Description

Currently, most (all?) of our meta framework SDKs enable source map generation even if users explicitly disabled sourcemap generation in their build config. While this improves the onboarding experience because Sentry "just works", it is intrusive and overrides a quite critical user decision. In most frameworks we emit build logs that we do this but it's nevertheless questionable behaviour.

Therefore, we decided to change the behaviour with the next upcoming major for all stable meta framework SDKs:

• If users explicitly disabled sourcemaps (e.g. build.sourcemaps: false in Vite), we respect this and emit a warning that errors won't be unminified in Sentry. We will not upload anything.
• If users set source map generation to any other value that effectively enables them (true, hidden, inline, etc). We respect this and don't do anything (i.e. deletion) besides uploading. Uploading will still emit build logs as today.
• If users don't explicitly enable/disable set source maps generation, we
  • enable hidden source maps generation
  • configure filesToDeleteAfterUpload to delete all .map files
  • emit a log that this is what we're doing for transparency

For stable SDKs, this change is behaviour-breaking with significant user impact. So we will only do this in the upcoming major.

### Stable SDKs 
- [ ] NextJS
- [ ] Remix
- [ ] Astro
- [ ] SvelteKit
- [ ] Gatsby(?)

For SDKs currently in beta, we can change this right now, which is also a good opportunity to trial the new behaviour

### SDKs in Beta
- [x] Nuxt: https://github.com/getsentry/sentry-javascript/pull/14020
- [ ] https://github.com/getsentry/sentry-javascript/issues/13994

Considered Trade-offs

• If users explicitly disable source maps, errors will no longer appear unminified in Sentry (since we don't upload anything). This is a UX decrease in Sentry but it is compensated by being a good citizen on the SDK side. We will emit clear warnings that this is problematic and ask users to enable and delete or unset their source map generation settings.
• Theoretically, other bundler plugins could modify the source map generation setting prior to our plugin coming in and checking the previously set value. We cannot detect this. For now we'll live with this trade-off and evaluate how much of a problem this actually is.
• Some frameworks (like Nuxt) recognize during build if source maps are emitted and might change the build output (for example, list the source maps as routes in a routing manifst/table). If we delete source maps afterwards (case 3), this might cause build or runtime issues/warnings/logs. We'll need to find framework-specific solutions how to address this. For instance, we could try to modify the route manifest file and remove the entries again.

[s1gr1d]

Maybe something we should keep an eye on: Nuxt sets sourcemaps.client: false per default (docs here) and users have to explicitly enable this when the SDK respects a disabled sourcemap setting. We might make an exception here and always enable with "hidden".