fix(node): Convert debugging code to callbacks to fix memory leak in LocalVariables integration

[timfish]

Closes #7230

This PR converts the LocalVariables debugger code to callbacks so that we can call Debugger.resume synchronously from the pause callback which fixes the memory leak.

It's worth noting that now there is no usage of async, it will not be possible to use async import to improve this:

sentry-javascript/packages/node/src/integrations/localvariables.ts

Lines 32 to 35 in 0743e98

	TODO: We really should get rid of this require statement below for a couple of reasons:
	1. It makes the integration unusable in the SvelteKit SDK, as it's not possible to use `require`
	in SvelteKit server code (at least not by default).
	2. Throwing in a constructor is bad practice

I created a basic Express server to test these changes and load tested an endpoint with a caught/handled error to see if any memory is leaked. Without the async code, performance is also much improved:

	Before	After
Requests/sec	40	220
Av. Latency	90ms	40ms
Peak Memory	570 MB	130 MB

[mydea]

LGTM! We can think about using await import later, for now it's more important to fix/unblock this IMHO 👍

[AbhiPrasad]

Should we clear the callbacks list here? Otherwise there is a risk of complete being called multiple times right?

[timfish]

I think it can only get called twice if a function passed to add calls next before throwing and in every current usage next is called last.

Maybe add a throw if complete is called and there are still callbacks remaining?

[AbhiPrasad]

Should we no-op if callbacks is empty? Perhaps give some kind of indicator of success (boolean return) from the next function?

[timfish]

Since we add complete to the top of the callbacks stack, the only way next can be called when callbacks is empty is if you call next more than once per added closure or manage to call next in complete (which would be tricky to do since you have to supply complete before next is returned). The || callback here is mainly to keep the types happy and does not get hit currently.

If we don't expect to hit this path, maybe it would be better to throw if pop returns undefined?