extract to portable integrations

[linear-code]

Follow the example of the portable express instrumentation in #19928

Each of these dependencies in packages/node needs to be:

• Extracted out to a standalone patching library that receives the module export as an option, outside of the node package.
• Loaded into the node sdk with a bare-bones opentelemetry/instrumentation instance.

Consider creating a new packages/integrations to house these, which can be done as a subsequent step (for now, just leaving in packages/core/src/integrations is fine.)

• @opentelemetry/instrumentation-express feat(core, node): portable Express integration #19928
• @opentelemetry/instrumentation-amqplib
• @opentelemetry/instrumentation-connect - extremely similar to express integration
• @opentelemetry/instrumentation-dataloader
• @opentelemetry/instrumentation-fs
• @opentelemetry/instrumentation-generic-pool
• @opentelemetry/instrumentation-graphql
• @opentelemetry/instrumentation-hapi
• @opentelemetry/instrumentation-http - We already have a TracingChannel integration in node-core. Patching style integration can be additive, especially if deno/bun node:http impls don't use TCs. If they do, this can possibly be discarded? (investigate)
• @opentelemetry/instrumentation-ioredis
• @opentelemetry/instrumentation-kafkajs
• @opentelemetry/instrumentation-knex
• @opentelemetry/instrumentation-koa
• @opentelemetry/instrumentation-lru-memoizer
• @opentelemetry/instrumentation-mongodb
• @opentelemetry/instrumentation-mongoose
• @opentelemetry/instrumentation-mysql
• @opentelemetry/instrumentation-mysql2
• @opentelemetry/instrumentation-pg
• @opentelemetry/instrumentation-redis
• @opentelemetry/instrumentation-tedious
• @opentelemetry/instrumentation-undici
• @prisma/instrumentation
• @fastify/otel

[linear-code]

JS-1987

[linear-code]

from isaacschlueter:

Alternatively, rather than creating a new package (which imposes some complexity in publishing Yet Antoher package, keeping versions pinned, etc) we could also put them outside of the default export, in something like @sentry/core/integrations so they're only pulled in by the SDKs that actually use them. (Or even, if we didn't mind having a giant package manifest, @sentry/core/integrations/<module-name>, but that might be more annoying for not much more tree shaking ability?)