[Gitflow] Merge master into develop

Adds support for new error handling utilities of Remix v2.
([ErrorBoundary](https://remix.run/docs/en/main/route/error-boundary-v2),
[handleError](https://github.com/remix-run/remix/releases/tag/remix%401.17.0))

## `ErrorBoundary` v2

Remix's `ErrorBoundary` captures all client / server / SSR errors and
shows a customizable error page.
In v1, to capture client-side errors we were wrapping the whole Remix
application with `@sentry/react`s `ErrorBoundary` which caused
inconsistencies in error pages. (See:
#5762)

v2 implementation does not wrap user's application with
`@sentry/react`'s ErrorBoundary, instead it exports a capturing utility
to be used inside the Remix application's `ErrorBoundary` function.

Can be used like:

```typescript
import { captureRemixErrorBoundaryError } from '@sentry/remix';

export const ErrorBoundary: V2_ErrorBoundaryComponent = () => {
  const error = useRouteError();

  captureRemixErrorBoundaryError(error);

  return <div> ... </div>;
};
```

It also requires `v2_errorBoundary` [future
flag](https://remix.run/docs/en/1.18.0/pages/api-development-strategy#current-future-flags)
to be enabled.

## `handleError`

For server-side errors apart from 'Error Responses' (thrown responses
are handled in `ErrorBoundary`), this implementation exports another
utility to be used in `handleError` function. The errors we capture in
`handleError` also appear on `ErrorBoundary` functions but stacktraces
are not available. So, we skip those errors in
`captureRemixErrorBoundaryError` function.

`handleError` can be instrumented as below:

```typescript

export function handleError(error: unknown, { request }: DataFunctionArgs): void {
  if (error instanceof Error) {
    Sentry.captureRemixServerException(error, 'remix.server', request);
  } else {
    // Optionally
    Sentry.captureException(error);
  }
```

- Adds the `ModuleMetadata` integration that fetches metadata injected via bundler plugins and attaches is to the `module_metadata` property of every `StackFrame`. 
  - This can later be used in `beforeSend` or another integration to route events depending on the metadata.
  - This integration is 
    - Exported separately from `@sentry/core` (ie. not in `Integrations`) so it doesn't get included in default bundles
    - Exported separately from `@sentry/browser` so that it can be used without depending directly on core
- Uses the `beforeEnvelope` hook to strip the `module_metadata` property from stack frames
- Adds a test to ensure `module_metadata` is available in `beforeSend` and is stripped before sending

As long as our SDK and `[email protected]` aren't compatible, we need to
hard-pin our NextJS integration tests to `13.4.9` to unblock our CI.

We need to revert this change once we figured out 13.4.10! (Set a reminder
for myself)

When an error occurs in `beforeAddRecordingEvent`, we just skip this
event and log the error.

Closes #8542

Apparently accessing sessionStorage in an iframe with certain
permissions can result in a throw, so we try-catch this to ensure we do
not produce any errors.

Closes #8392

Noticed the commands are a bit off, so fixed them!

Turns out, `HTTP_TARGET` is always the relative path, even for outgoing
requests, which omits the host. So we handle this specifically now here.

While at it (and as I'm working a bit in this codebase), I also renamed
the files from kebap-case to camelCase, to align with the rest of the
codebase better - unless there was a specific reason to use that here
@AbhiPrasad ?

Closes #8535

As reported in #8541, our NextJS SDK currently breaks dev mode for the
newest NextJS 13.4.10 version

I still have absolutely no idea which of the changes in
[13.4.10](https://github.com/vercel/next.js/releases/tag/v13.4.10) is
causing this.
However, I traced the error back and it happens as soon as our NextJS
SDK package requires @sentry/webpack-plugin:

* @sentry/nextjs calls `require('@sentry/webpack-plugin')`
* @sentry/webpack-plugin calls `const { RawSource } =
require('webpack-sources');`
* For _whatever_ reason, NextJS can't require `webpack-sources` and
throws

Since we don't enable our Webpack plugin [in dev

mode](https://github.com/getsentry/sentry-javascript/blob/723f851f358b75cd39da353804c51ff27ebb0c11/packages/nextjs/src/config/webpack.ts#L305)
anyway, one way to get rid of this error is to only require it if we're
_not_ in dev mode.

This hotfix therefore moves the top-level require of
`@sentry/webpack-plugin` to a dynamic require. This isn't a great
solution and honestly quite ugly but if it unblocks users for now I'd
say we merge it. I think we should definitely revisit this though once
we know more about why NextJS suddenly isn't able to import
`webpack-sources`.

closes #8541

Protocols are from https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids which don't exactly match the OSI. We can consider adding a lookup table later if people are finding this insufficient.

Co-authored-by: Abhijeet Prasad <[email protected]>

…8559)

The multiplexed transport can already route events to different or
multiple DSNs but we also need to be able to route to specific releases
too.

In a page with micro-frontends, it's possible (and probably even quite
common) to be using the same dependency multiple times but different
versions (ie. different releases). Depending on where an error occurs we
might want to send an event to `[email protected]` or
`[email protected]` at the same DSN.

This PR:
- Adds a private `makeOverrideReleaseTransport` which can used to wrap a
transport and override the release on all events
- Modifies `makeMultiplexedTransport` so it now creates a transport for
each unique dsn/release pair
- And uses `makeOverrideReleaseTransport` whenever a release is returned
from the callback

Co-authored-by: Abhijeet Prasad <[email protected]>