Tunneling: Improve JavaScript SDK API

### Description

ref https://github.com/getsentry/projects/issues/385 and https://www.notion.so/sentry/Project-Improve-Tunneling-1368b10e4b5d80b38557c66fbcf6d8a1

Right now there is a singular option for `tunnel` in `Sentry.init` that you pass in to enable tunneling. This makes setup very simple, which is a positive, but it has drawbacks.

1. Complicates SDK internals because we end up passing tunnel config everywhere
2. No finely grained control over what gets tunneled (a user may decide to tunnel only errors so that there is less load on their proxy infrastructure they set up). This came up in https://github.com/getsentry/sentry-javascript/issues/13520.
3. We always send to tunnel endpoints, even when end-users don't have a adblocker set up
4. There is a very slight bundle size increase (but not that important): https://github.com/getsentry/sentry-javascript/pull/14223

To address this, we should improve the tunneling API within the Sentry SDKs

## Investigate

1. Do ad blockers block based on envelope payload? If they do, we might need to investigate alternate formats.

## Explore

1. Explore alternate ways to configure tunneling in the SDK. https://github.com/getsentry/sentry-javascript/issues/14152 raises a custom transport, but perhaps an integration also works well.

## Implement

1. Can we detect in our SDKs if an ad blocker blocks our requests? If yes, we could try to send the data first directly to Sentry, and if it doesn't work, use the tunnel.

With that approach, we take most of our load from our user's infrastructure. Furthermore, we could identify how much data comes through the tunnel and how much directly via Sentry when adding metadata to the tunneled envelopes. We could also share that data with our users.