feat(node): Expose getHttpInstrumentationOptions utility

[mydea]

Related to getsentry/sentry-docs#11378

It can be a bit tricky/annoying for users with a custom otel setup to understand that they cannot add their own HttpInstrumentation, because this will overwrite ours which we need.

This PR exposes a new utility, getHttpInstrumentationOptions(), which can be used to define your own HttpInstrumentation:

registerInstrumentation({
  instrumentations: [
    new HttpInstrumentation(Sentry.getHttpInstrumentationOptions())
  ]
});

this way it does not matter that/if that overwrites the instrumentation we added in the first place, http instrumentation will still work as expected then.

[AbhiPrasad]

Don't we have to re-export getHttpInstrumentationOptions in the metaframeworks as well?

It's a little annoying that we have to put getHttpInstrumentationOptions in the top level namespace, but I guess not a good way to go around this unless we add another field to httpIntegration (like Sentry.httpIntegration.getHttpInstrumentationOptions()). What do you think about that?

[mydea]

Don't we have to re-export getHttpInstrumentationOptions in the metaframeworks as well?

It's a little annoying that we have to put getHttpInstrumentationOptions in the top level namespace, but I guess not a good way to go around this unless we add another field to httpIntegration (like Sentry.httpIntegration.getHttpInstrumentationOptions()). What do you think about that?

My reasoning was that as of now we don't really care (and/or support) custom otel setups for the meta frameworks (yet), so it's not necessary to re-export this there - but no strong feelings about this!

I also agree that it would be nice to group this somewhere, but I also always find it a bit counter intuitive to have props like this on functions 🤔