Gamelab: add this.debuggerEnabled to avoid leak

[cpirich]

• Gamelab now maintains a this.debuggerEnabled state variable to remember whether or not it needs to worry about the debugger. Previously, it checked showDebugButtons || showDebugConsole only for calling jsDebugger.initialize() and potentially jsDebugger.open(). But, it would still call attach(), detach(), and appendLog() when it didn't really need to.
• While this does makes things a tiny bit faster when there is no debugger around, the more important reason to make this change is that we were leaking a JSInterpreter instance for each Run/Reset when we did this, but only on Blockly gamelab levels. The Blockly instance holds out to a previous redux store state, that contains the previous JSInterpreter (even though we did properly null out the jsInterpreter state during jsDebugger.detach()). This may warrant further investigation, but the change above avoids the massive leak of JSInterpreter, p5, and everything else attached.
• Heap snapshot reference trace:

[cpirich]

@islemaster look good to you?

[islemaster]

Sorry, I missed this yesterday, looking now.

[islemaster]

🎉 Great find! I would not have guessed this. Do you recommend any particular change to our process that would keep us from accidentally re-introducing this leak?

[cpirich]

I’m a little worried about what Blockly is doing and why the store is out of sync.

Additionally, I’m think we should avoid placing important objects like the JSInterpreter in the redux store.

As for how to catch it if we reintroduce it, maybe there is a way to run unit tests with heap snapshots afterward?