Move Node specific code to `@sentry/node`

[AbhiPrasad]

### Node
- [ ] https://github.com/getsentry/sentry-javascript/pull/7503
- [ ] https://github.com/getsentry/sentry-javascript/pull/7503

For Node we probably just want to update the docs to match OpenTelemetry:

const Sentry = require("@sentry/node");

Sentry.init({
  integrations: [...Sentry.autoDiscoverNodePerformanceMonitoringIntegrations()]
});

[timfish]

@AbhiPrasad how were you thinking autoDiscoverNodePerformanceMonitoringIntegrations would work?

autoDiscoverNodePerformanceMonitoringIntegrations could simply return an array of integrations as they are but many of them will log warnings when loadModule fails in setupOnce. This is also in no way "auto discovery"

I can see that some integrations won't work without constructor options so they should not be considered.

It looks like the Apollo and GraphQL integrations are not currently loaded automatically via _autoloadDatabaseIntegrations but it looks like they can support auto initialisation.

What should be prioritised in the design? Do we need to keep the usage of dynamicRequire so that the integrations are never picked up by a bundler? if autoDiscoverNodePerformanceMonitoringIntegrations doesn't find any integrations we can assume a bundler is in use and warn that the integrations will need selecting manually.

Current plan is:

• Attempt to load the integrations like in _autoloadDatabaseIntegrations to keep them out of bundles
• If none are found, log a warning about how autoDiscoverNodePerformanceMonitoringIntegrations doesn't work with bundlers and integrations will need to be imported individually
• Modify all integrations so loadModule code is in another method we can call separately (like loadDependencies())
• Cycle through integrations and only return those where loadDependencies returns true

[AbhiPrasad]

how were you thinking autoDiscoverNodePerformanceMonitoringIntegrations would work

Yeah this is tricky. I think your plan should suffice for now, but let's see if that changes.

It looks like the Apollo and GraphQL integrations are not currently loaded automatically via _autoloadDatabaseIntegrations but it looks like they can support auto initialization.

We did this intentionally because we had plans for v8 to remove the auto initialization all together, but maybe this changes.

[timfish]

• Modify all integrations so loadModule code is in another method we can call separately (like loadDependencies())
• Cycle through integrations and only return those where loadDependencies returns true

I'm going to leave these out of the initial PR to keep it smaller and this adds additional behaviour over the existing _autoloadDatabaseIntegrations

[AbhiPrasad]

Closing, let's add the docs task and any other clean up to #5815